Permissions design
In ATiM, permissions are managed by ACL. A user with proper privileges can manage them through the administration module.
Contents |
Design
Access Control Object
Three levels of hierarchy for ACO (Access Control Objects) are present in ATiM. At the top we have the plugins (ex.: inventory), at the middle we have the components (ex.: collections) and at the bottom we have the functions (ex.: add).
Access Request Object
Two levels of hierarchy for ARO (Access Request Objects) are present in ATiM. At the top are the groups and at the bottom the users. Although two levels exists, permission can currently only be assigned to groups.
Groups
Groups are a mean to manage user permissions. They can only be created by super administrators. Once a group is created, users can be added to it. The purpose of a group is to:
- Have some users sharing permissions (thus an administrator can quickly change the permissions for multiple users under a same group).
- Have some users grouped under a bank (it is planned that at some point users of a bank will not be able to access the inventory of other banks).
Intended design
Currently, a user cannot be part of multiple banks. That means that if a person needs to have access to multiple banks, one must either
- Create more users for the same person (encouraged)
- Grant super admin privileges to that person (discouraged)
It is intended to develop user profiles to solve that issue. Those profiles would become virtual users. The concept is quite simple. A user would connect to ATiM. If he has multiple profiles, he will be asked to pick one for the working session. Then, permissions would be assigned to that profile (virtual user) rather than to the user directly. Since a user can have many profiles, it would be possible to give different levels of access to different banks to the same user simply by creating new profiles.
