User Permissions is still a pain. On ERPNext Cloud the highest number of setup queries are regarding user permissions and we need to fix it.
The core reason this fails is that there 3 keys to user permissions
User
Role
DocType
and you need to edit two views to set them
Role Permission Manager (Apply User Permission - select doctypes)
Make “User Permission” Rules.
This is NO VIEW that helps you to understand the permissions
Here is our proposal:
Remove roles from user permissions
How this will help? There will be only one view to set user permissions, just create the “User Permission” records and based on this, the user will see only those which the user has been assigned for that doctype (not extrapolated to user)
Use Case
Restrict User A to Project X and Y
Before
This has probably 15 steps
Go to all DocTypes (like Tasks, Invoices, Expenses) that have “Project” link and check “Apply User Permission”
Select “Project” DocType in each of them
Create “User Permission” record for User A for Projects X and Y
Pray
Expected outcome:
All Tasks, Invoices, Expenses etc restricted for User A to Projects X & Y
(Note: provided, the user does not have another role that allows)
After
Create User Permission record for User A to restrict Project X & Y
Relax
Expected outcome:
User A restricted to all transactions that have “Project” link to Projects X & Y
Ignore User Permissions check?
That will still apply!
Please let us know your views!
Edit:
We can also apply granular permissions by adding an option in “User Permissions” to apply to all linked DocTypes or specific ones.
What happens to the “If Owner” option in Role Permissions Manager?
I still say the solution is using good defaults. By default, “Apply User Permissions” and all doctypes under apply user permissions should be checked. This results in the same “After” outcome noted above and is the least disruptive change.
Also, get rid of “Set User Permissions” - that seems pointless.
Roles provide a logical way to group users in an organization that perform similar functions with similar rights. Once a role is created it can be re-used over & over again.
If the proposal is to only handle exception scenarios of data security without roles being mandatory, it makes sense. However, if it is suggesting to remove roles totally, I do not agree to it. I assume you mean to just make setting specific user permissions easy.
This is good. Don’t forget to offer an option to “hide” doctypes from the main explore menu. A classic example is showing company under accounts for a basic user. The admin should have the ability to show/hide any doctype for any user (even if they maintain the ability to read the doctype).
Also, add settings to provide security on the attachments for a doctype.
I don’t think you should get rid of roles. Those are a huge help to @Pawan comment.
The user permission manager has been a real pain. Hopefully this will make things better. It sounds good, but I’d have to see it in action to really understand it.
Agree… It was working that way in V7 backwards… Now the new design in V8 onwards always show doctypes even they don’t have permission at all.
I found that we either must remove all role permission for that doctype including for System Manager or remove the roles from doctype json directly…to make those doctypes really disappear from menu…
I just don’t understand the reason behind this design… It seems the system manager doesn’t has full control to show and to not show doctypes… Hope this will be reviewed too…
What happens to strict user permissions like if we have restricted user permissions enabled?
There is a use case that when we limit the users by a doctype and then on creating a new user no doctype is linked to that user, in that case, the new user would be able to see all documents without LIMIT which is HIGHLY undesireable.
Strict permissions can easily be handled by not giving the relevant role. There is no point giving Role permissions and then restricting everything with User Permission.
Don’t know about feasibility, but maybe just retain the “strict” functionality which is in place right now. If “strict” is enabled, then by default, user has access to nothing. Otherwise, by default, user has access to everything.
I think the problem is because we can approach the permission from several angles: user, role, DocType.
On the other hand, a person can also be approached from several angle : role in the company/business (employee/customer/supplier/etc), user (of the system), role (in the system).
Creating the matrix of these 2 factors (permissions and person) is difficult (900+ combinations by default).
My suggestion for the workflow to setup permissions is:
set system-role (mapped from business role) with all the permissions based on the module allowed (and drill down to DocType if want granular setup).
set persons information and set the user account (if necessary).
apply the system role to this person/user. It can be multi-roles.
So no user-oriented permissions.
Example of use case:
An employee who is not ERPNext user can be recorded in the employee data.
– Set the role as “non user employee” who doesn’t have any permissions.
A purchasing employee can be recorded in the employee data.
– and set the role as “purchasing staff” who has permissions to access buying module.
– he can also be given role as “warehouse checker” to access warehouse DocTypes.
Hi,
You mean on a doctype you have to add one more layer of security applied on doctype’s records where grants will be given for a role(s) or a user(s).
Yes it’s possible. System should check this layer for each doctype.
I want to add effectivity dates for this grant, suppose we grant for a specified period of time then system will revoke it automatically without any extra effort.
create/change/display sales order in user’s own company, display sales orders in other company
create/change stock entry for material receive(purpose), display all stock entries, the purpose field in stock entry is selection other than link field, is possible to restrict it via user permission?
sales team leader manage(create/change/delete) sales orders under his team, sales team leader can also display other teams’ sales order, but sales person can only create/change his/her own sales order.
I think this is a bit different but now, instead of managing roles, you have to manage users. So the complexity has just moved. I think if we can build an equivalent of User Permissions but make that Role Profile permissions so that, a group of users can be managed with a single entry.
Access Rights alignment is a complex process in every system, so I don’t think we should shy away from the complexity. Simplicity can be achieved only at the cost of granular control. I liked the granular level of control of the previous configuration.