Replies: 3 comments
-
|
xref existing tickets incl
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Would you mind to elaborate this?: |
Beta Was this translation helpful? Give feedback.
-
|
@tovari It means that the groups are created using a script from the code base with specific set of permissions, but it can be changed / updated from the admin panel which now is different from what's mentioned in the code base. We have a lot of places in the code base where the permissions are assumed to be static and in the format that we populated it using the scripts. This can potentially affect the behavior of the system and cause unexpected results. So, to avoid this scenario, we're aiming to make all the permissions and roles static (i.e not modifiable from admin panel or the database). The aim is to make those permissions invisible to the admins (Those who manage the users) and provide a simplified interface only with the roles, which can be assigned to or revoked from the users. |
Beta Was this translation helpful? Give feedback.
-
Permission System
In software development, a permission system is a system that defines and manages the access rights and privileges of users within a program or system. It outlines the rules and guidelines for granting or denying specific actions based on the roles, permissions, and levels of authorization assigned to individual users or user groups. This helps ensure the security, integrity, and confidentiality of data and resources by controlling who can access, modify, or execute certain actions.
Background
User roles in IFRC GO
There are different user roles in IFRC GO. Each role has different access rights and privileges within IFRC GO.
The existing user roles in IFRC GO are listed below:
We should note that some of the roles should be associated with a country or a region.
The user roles associated with a country are listed below:
The user roles associated with a region are listed below:
Visibility in IFRC GO
There are different type of entities in IFRC Go. And, there are different kind of visibilities that depend on the entity and the logged-in user:
The entities that we are interested for this discussion are listed below:
User profiles in IFRC GO: Country and Region
Current Implementation
The permission system is implemented using Django's built-in permission system. Only Super User of IFRC GO can view and manage the permissions using the Django Admin Panel.
Permission
The available permissions are listed below:
List of permissions extracted from IFRC GO production (2024-04-10)
Permission Groups
The available permission are listed below:
List of permission groups extracted from IFRC Go production (2024-04-10)
Shortcomings
Admin Panel Access
Admin Panel by-passes all the guards in-place that ensures data integrity.
Permission can also be updated directly resulting in unexpected results.
Permissions and groups are not discoverable
The internal implementations of a permission system should not be exposed to the user. We currently have 608 permission groups in Django Admin Panel which is not even close with the user roles discussed above.
These followings queries cannot be easily answered from the UI provided by the current permission system:
Inconsistent implementation of roles and permissions
Permission should be granular.
Permissions should be define a certain action or access. For example,
Here, the permission is clear, concise and self descriptive. It describes one single action.
We should avoid permission that defines multiple action or unclear action. For example,
Here, we do not know what underlying actions a PER Admin for Nepal can perform. Or, what sort of actions are applicable with this permision. This defines more of a "role" than a "permission".
Permission should not be coupled with a particular entity (e.g. Country or Region)
We should not have permissions like DREF Admin for Africa since it is coupled with an entity (i.e. Africa Region).
The same permission group but for different countries should not have different permissions
Since we're creating a separate permission for each country (or region), it is possible to have different privileges on same type of permissions.
E.g. We cannot be sure that Nepal Country Admin will have similar level of privileges to Afghanistan Country Admin
Suggestions
Separate out Roles and Permissions
Implement an abstraction layer over Django's built-in permission system
We should add a layer of abstraction to extend the application of permissions to our need in the GO.
We can group the existing roles into the following:
System Roles
Country Roles
Regional Roles
Simplify and move user management UI in GO web application
We should add a new page that will be visible to users that can view and manage permissions.
Appendix
We should clearly define the list of actions that can be performed by each roles in this Google sheet.
IFRC GO Permission Matrix
Beta Was this translation helpful? Give feedback.
All reactions