Accomodate Complex Permissions

[batpad]

We need to accomodate flexible and complex permissions across the GO platform. We need to be able to define fine-grained read / write permissions for users on different objects, as well as permissions based on the user's role and / or membership within a national society or as a regional administrator.

So far, permission constraints have been added to the backend on a fairly ad-hoc basis based on specific needs and use-cases. We currently handle permission constraints in a few different ways:

• Controlling Visibility with a visibility class that allows things to be viewable only for IFRC users (eg. Field Reports and Projects): https://github.com/IFRCGo/go-api/blob/develop/api/visibility_class.py#L19. This is done by checking if the user is an admin or has a permission assigned:

  go-api/api/utils.py

  Line 43 in bcbd290

  if user.has_perm('api.ifrc_admin') or user.is_superuser:

• On PER, we check country-specific permissions for users, which can be assigned in the Admin: https://github.com/IFRCGo/go-api/blob/develop/per/admin_classes.py#L17 . These permissions can be assigned in the Admin, and there is a script to create the permission classes / names: https://github.com/IFRCGo/go-api/blob/develop/api/management/commands/make_permissions.py (this is also used to assign permission to languages to edit translations)
• ... @szabozoltan69 @thenav56 could you please add to this list any other examples where and how we enforce some kind of user permissions?

So, broadly, we are using the Django Permission system to create permission classes and add those permissions to users, and then check if a user has some permission in the code to perform some action (ref https://docs.djangoproject.com/en/4.1/topics/auth/default/#permissions-and-authorization).

This is definitely awkward for things like "permission for a country", where we go through a step of creating these permission names in the admin instead of having a direct relation between the User and Country models in the database.

I guess the first question here would be: should we continue using the in-built Django Permissions system and largely go with the same approach of creating permission names / classes in the Admin and assigning users to have those permissions as needed. OR if we would model this entirely differently. @thenav56 this question is mostly for you :-)

I am not really opposed to either approach - I can see how the current approach will start falling down a bit once we need to do more fine-grained permissions, and this approach of auto-creating permission classes based on model names in a cronjob seems extremely brittle. I also think that if we have to, we probably can accomodate a fair amount of use-cases with the current approach.

@thenav56 it will be really nice to see a rough outlay of what implementing a better permission model will look like. Am happy to then look at the existing permissions and see how it would map to this new model. We can also discuss if there is any possibility of cleaning up / using the current approach and not doing a completely new permission model - my personal thought is that the in-built django permission model does not work well for the kind of things we want to do, but I could be wrong.

cc @tovari

[bewakes]

@batpad @frozenhelium @thenav56 @tovari

Based on our discussion earlier and the matrix present in excel file(presented by Daniel), I have the following comments/questions:

Roles(from excel file)

• SuperUser
• Regional Admin
• Delegation Admin
• Emergency Admin
• IFRC Admin
• Donor/Partner
• Country Admin
• NS Staff
• NS Volunteer
• ICRC User
• PMER
• PER Country Admin
• PER Regional Admin
• PER team
• DREF Admin
• DREF Regional Coordinator
• DREF Coordinator(NS)
• Fed-wide admin
• Fed-wide Data Manager

QUESTION 1: Are these roles going to be the new visibility roles(currently: IFRC, NS, Member, Public)?

QUESTION 2: Can a person have multiple roles? Example: Can a user be both DREF Admin and Regional Admin?

QUESTION 3: Do the above roles have some order/hierarchy(Example: Donor > Partner > ...)? But I guess they are module dependent(DREF, PER, etc)

QUESTION 4: Can a person be involved in multiple regions/countries?

QUESTION 5: How might the roles increase as modules increase?

Currently, we have visibility levels defined for entities like FieldReport. They
are hierarchical i.e. given a level, any level equal or above it can view the
item.
QUESTION 6: Are there entities that require non hierarchical visibility? If so please provide examples.

QUESTION 7: Do we need to have fields similar to "visibility" which dictate who(or which level) can edit/delete/publish/etc? If so please provide example.

QUESTION 8: Might we need to provide access to certain users only for some entities(say, I want this Field Report to be accessible by Daniel and Luke only)? If so please list the entities/examples.

[nanometrenat]

xref discussion at IFRCGo/go-web-app#853