Want to share with you reference about architecture of Access rights in Acumatica.
This knowledge you can use for
- Sharing data between companies
- Copy data between companies for faster implementations
- Mass update of access rights with database
- Just for fun 🙂
All acumatica access rights are located in the 6 different tables: Users, Roles, UsersInRoles, RolesInGraph, RolesInCache, RolesInMember. Lets check all of them.
Users – main entity that stores information about user. User management is done though
This table includes such user configurations as password, name, email, password settings and some statistics.
Roles – the main table that stores names and description of roles. Roles do not have any specific configurations so the table is rather small.
UsersInRoles – this table contains mapping between users and roles. Many to many relationship. You can edit this table from Users and Roles screens.
RolesInGraph – This table contains Access rights for screens. Even if table has “Graph” in name it is still access rights per screen but the name is just a legacy from time when access rights were defined per graph.
Table contains many-to-many relationship between screen ids and roles. This table can be edited from from “Access Right By Screen”, “Access Right By Role”, “Access Right By User” screens when you choose entity that has screen id (Screen, report, inquiry, folder). Basically any sitemap node with ScreenID.
RolesInCache – This table is edited from the same screens as the table above but is used when you select any container control associated with DAC like form, tab or grid.
RolesInMember – the same approach as above but for end fields and actions. If you select in “Access Right By Screen”, “Access Right By Role”, “Access Right By User” screens field or action (related to that DAC) you will be able to edit access rights to that field/action.
All Access rights are defined by following levels:
- Delete – you can see, create, change and delete all records/fields.
- Insert – you can see, create and change records/fields but not delete
- Update – you can see and change records/fields but not create or delete
- Select – you can see records/fields but cannot change, create or delete them
- Revoked – you cannot see or change records/fields
Each Higher level included allowed operations from lower level.
Mapping for DB Value: “Not Set” -> -1, “Inherited” -> -1, “Revoked” -> 0, “View Only” -> 1, “Edit” -> 2, “Insert” -> 3, “Delete” -> 4, “Granted” -> 4.
As a separate thing we have – Non Set configuration. It works differently depend on have you configured access rights for any role or not:
- If you have not configured access rights for that node for any role that this screen/field will be visible and accessible for everyone. This is needed for faster adding of reports/inquires
- If you have defined access rights at least for one role, this screen/field will be visible and accessible only for specified roles.
Hope it helps and have a nice day!
2 Replies to “Access Rights Database Reference”
I found access rights for Approve and Reject button in Sales Orders difficult to configure in the 2020R2 version if the user has multiple roles. The scenario is that the user was given a temporary role to approve the Sales Order. The first role allows the user to edit sales orders but is not allowed to approve/reject. The other roles allow the user to approve/reject only. If these roles are both enabled, the button does not appear.
The worst part is the new action buttons in this version like the release from credit hold, put on hold, and etc are enabled even the access rights in the screen is view only.
Hi Fritz, for me it seems like a bug, so I suggest to create a case for that