Re: [Codematch-develop] DataTracker and CodeMatch access control

[Robert Sparks <[e-mail]>]

Hi Lisandro -

Before we go too deep into this, I want to call out a way we expected 
Role to be used and make sure you've considered it.

You are not necessarily restricted to the Role names that are defined 
now (like "chair"). We could add Role names like
"codematcher" or "codematch_approver" or whatever other name matches the 
semantic for the permission you're wanting to manage.

You could then have things like Lisandro Granville is codematch_approver 
in nmrg.

Does that address the need? If not, could you walk me though a scenario 
where it makes it harder than it should?

RjS

On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote:
> Dear All
>
> Last week we had our traditional CodeMatch meeting. One of the questions discussed in the meeting was about role-based access control (RBAC) in CodeMatch. We would like to propose adding an extra table in the current data model to support RBAC. However, because we want to be as aligned with DataTracker style as possible, we are sending this message to start a discussion, specially with Henrik and Robert.
>
> 1) Style of checking users’ permission
>
> We observed the DataTracker code and it seems that in general, permission checking is hardcoded, in the following style (using “Area Director”, “IAB Chair”, and “Secretariat" as examples):
>
> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat"]):
> 	// do something that only area diretor, IAB chair, and secretariat could do, like “Create CodeRequest"
>
>
> In CodeMatch, we would like to check permissions in the following way:
>
> if has_right(request.user, “Create CodeRequest”):
> 	// do something that only authorized people should be able to do, like “Create CodeRequest”
>
> The “has_right” function would check the database to retrieve the users’ roles and, for each role, check if it has permission to “Create CodeRequest”. In this way, permissions are associated to roles, and roles associated to users.
>
> Because permissions and roles in CodeMatch are being defined together with the implementation of the system prototype, the use of “has_right” would allow us to assign permissions to roles just changing the database, instead of changing the CodeMatch code if we use “has_role” instead.
>
> 2) Database
>
> Today, permissions are listed in table auth_permission. Roles are listed in table group_role. We would need a intermediate table linking permissions to roles, i.e., a table linking author_permissions and group_role. That would allow us to say, for example, that a mentor (inside group_role) can add documents to a codeRequest (i.e., a permission inside auth_permission). Adding this intermediate table (let’s call it role_permission for the moment) would not affect today’s database, although it would expand today’s data model.
>
> Do you think doing that is ok?
>
> Best regards,
>
> Lisandro, Wanderson, Matheus
>