[Codematch-develop] DataTracker and CodeMatch access control

[Lisandro Zambenedetti Granville <[e-mail]>]

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