I created a custom app which is dependant on some doctype of erpnext too
So while make a custom role for the new doctypes I also added the doctype which are used in my custom app…
But now it has overwritten it and only the that the doctype has permissions of the custom role
Also a doubt the permission level we had in roles
So how does that work
Like here we have a HR User Role which has employee checkin 0 and employee checkin 1
But When I select HR user both of them gets detected…So how does the permission level thing works
Regarding Custom Persm overriding Doc Perms, you have described the design correctly: Custom Perms override Doc Perms.
“Perm Level”, despite its name, is not hierarchical. “Perm Level 1” is not “higher” than “Perm Level 0”, just different. “Perm Level 2” is not “higher” than “Perm Level 1”, just different.
Hello @tmatteson Thanks for your reply
Okay so I would have to find a solution for Custom Doc prem
And for the Prem level
I am not understanding how it is used
Like As u can see HR User has Leave Application 0 & 1
So why not just make one …or how to use prem level
Sure. The part of the workflow here is that is basically undocumented is the difference between Doc Perms and Custom DocPerms. Doc Perms are the default permission that ship with a Doctype. These should only be changed in the context of a version control system (by a developer, more or less). The Custom DocPerms are what are exposed in the Pole Permissions Manager. This gives an ERPNext implementer a way have a default (Doc Perms) and then an override (Custom Perms). When an application like ERPNext is installed, all the Doc Perms are copied into the Custom DocPerms table.
You can confirm this by making a change in the Permissions Manager. Here I added the "Read’ permission for the Employee Self Service Role on the Doctype ‘Branch’:
You can see this change by navigating to the Custom Docperm record:
Consider our conversation an addendum or expansion to the documentation. It could probably use more concrete examples. Role Based Permissions
2 Likes
Hello Thank for this explanation…it gave a much better understanding of how things should be
But yes what I wanted to understand particularly is about prem level and how it is used
As i mentions that a particular role(HR role) has 2 different entries for same doctype with different prem levels …SO what happens when a user is assigned HR user role
How to assign prem level permission to a user
There is no functionality in the Frappe framework to have user-specific field-level permissions. Users change frequently but Roles tend to change less often. You should add a specific Role with the perm level you want and add that to the individual user. When they go on vacation or get fired or whatever the Role could be assigned to someone else.
Ohh Okayy So As my doubt still remains For many roles available there are 2 entries for same doctype with different prem level so why is that
So that one Role can view/edit a field with perm level 1 and another role can view but not edit and a third role can’t do either (no entry)
Heyy sorry to ask the same thing again and again …but I guess I am not framing my question correctly
In this role why are 2 leave application doctype why is that?
Yes. This presentation that shows the Custom DocPerms for Level 1. All other rows are for Level 0, exactly what it says. If you were to customize Leave Application to have a field with a Perm Level of 2, there would be three entries in this view.
Actually thats the thing I havent added any custom doc prem…its just plain erpnext and frappe
It’s from the default DocPerms. It’s part of Frappe’s base design.
1 Like
Hi together, I also came across a similar problem and I was wondering if this is as it was intended to be designed.
Coming back to the example from you @tmatteson from above: You have a DocType which was shipped with a default set of roles from ERPNext. Now you make a change and e.g. add a new role or change the existing permissions. All permissions are copied into the Custom DocPerms, decoupling from the default ones, which means no changes of the underlying permissions in the DocType will ever be applied again. Is this as it should be?
On the one hand I can understand it, the user decided on custom permissions, on the other hand I will e.g. also never see a new role which might have been added to a DocType (except it gets patched).
I am currently facing this issue by having a custom DocType in a custom app where the roles should be extended from another app (which makes any changes to the original roles in the json not being applied anymore).
Happy to hear other opinions on this topic!
@Leo Got it. In a custom app, you’ve decided in part that you need something different that what is the default in ERPNext.
I would argue that you are making a trade off here: that the permission opinions in your app should supersede ERPNext; the inverse would allow changes in ERPNext’s codebase to incorrectly permissions you have already configured. An example implication of this would be if a perm_level field changed and one of your users can now view privileged information. Another would be if you are using a Workflow, the user can now execute an ‘Approve’ step that they should not be able to.
If you want to override ERPNext’s default permissions, you are agreeing to maintain those changes as part of your business’ implementation. Ultimately, permissions are a configurable expression of company policy. If your ERP software requires you to change your company policy to something you don’t like, that’s bad.
1 Like
Hi @tmatteson yes, I think this makes sense after all. Since ERPNext doesn’t “know” which permissions to push over any user selection. For my use case I will most likely also follow the approach to only add very basic permissions in the DocType itself and add everything else in the Custom DocPerm.
Thanks for your quick response!
Br
Leo