ERPNext Foundation ERPNext Cloud User Manual Blog Discuss Frappé* Donate

[V11-Proposal] User Permissions Redux


#1

Dear all,

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

  1. Role Permission Manager (Apply User Permission - select doctypes)
  2. 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

  1. Go to all DocTypes (like Tasks, Invoices, Expenses) that have “Project” link and check “Apply User Permission”
  2. Select “Project” DocType in each of them
  3. Create “User Permission” record for User A for Projects X and Y
  4. 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

  1. Create User Permission record for User A to restrict Project X & Y
  2. 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:

  1. We can also apply granular permissions by adding an option in “User Permissions” to apply to all linked DocTypes or specific ones.

  2. Role permissions stay as it is.


[Version 11] Frappe permission manager "apply user permissions" missing
#2

#3

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.


#4

It is a good idea!

If there are no User Permission Records. Will the user have access to all Projects or will he have access to none?

So the user permission records will have to work something like simplified Linux firewall filter tables.


#5

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.


#6

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.


#7

No this is only for User Permissions - Role Permissions stay as it is.


#8

By default user has access to all projects, unless User Permission is created.


#9

That still remains


#10

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.


#11

I literally have to do the above anytime I tinker with permissions

It is a relieve to see that this is a general problem and not a result of my own ineptitude.

Do you mean not extrapolated to OTHER users?

This will be necessary

Regards


#12

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…


#13

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.


#14

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.


#15

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.


#16

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.


#17

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.

Regards,
Nofal


#18
  1. I’ve been trying to think if priority (like in case of pricing rules) can be used for user permissions.
  2. Permission rules (like pricing rules) could be added to specific user or role

#19

How to handle the following typical use case

  1. create/change/display sales order in user’s own company, display sales orders in other company

  2. 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?

  3. 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.


#20

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.

This one? I have to learn again.

Thanks

Jay