I believe there is a small bug in permissions.
When I create Permission Level 1 and uncheck Read and Write, it is the same as if Read is checked.
This will result in Employee able to see fields with permission level 1. In order to hide it, this row has to be deleted.
I think it’s not the bug and this is how it works.
But that seems illogical. If you must delete the the row, then it is no longer available for those with READ permission to see either. The permissions should be able to handle this situation.
BKM
Yes it seems illogical but I don’t have reason to add perm level and leave read and write unchecked.
I think the problem is that this even exits. I thought that leaving read and write unchecked means there is no read and no write access for that user group. I didn’t know that actually having no record in user permissions means no read/write.
I now understand it, but the question is, how many other users struggle with permissions? And having this option of leaving permission entry without any checkbox checked only creates more confusion.
For example - I want to restrict Employee from certain DocType. I can simply uncheck all boxes and leave it there, or delete whole line. Why leave line without any checks? Well, maybe as a reminder that there was something before:)
Anyway, I just thought I point this out to the community…
I think this gets to the heart of the problem. There is NOT a clear understanding of how the permission system works now. The documentation available currently is very old and the only people knowledgeable enough to document the new way the rules work are the ones that originally designed it.
How do we get them interested in explaining it to the rest of us?
BKM
refer to my proposal to refactor the current permisson system
even though I submit a PR User permission refactor by szufisher · Pull Request #6582 · frappe/frappe · GitHub
long time ago, due to so big change to the core involved, it was finally closed, seems that the current system’s permission issues are still there all the time, maybe we need to be more patient to wait for the core team to take actions on refactoring the permission system again in their own way.
Also this new proposal to control the permission via doctype variant on 3 levels( table, record and field)
Well, @szufisher as you have already personally learned, the probability of seeing changes that impact the core system is very remote.
They are far too afraid of creating a bigger mess than they already have at this time. That fear has essentially completely paralyzed their ability to even take on the fixing of many of the very bugs they created. That is why the man in charge said they would ONLY consider bug fixes that have been put through the PR system and are already tested and ready for merging, and of course only if they are submitted by the community at large.
I fear that the original design concept of keeping all business domains as part of the ever growing core system has finally grown the system to a size that is probably unmanageable at this time. That means that any little change can possibly ripple through to several unintended other parts of the system. It is probably too late to reorganize the project into a single Accounting system with everything else as add on apps or application modules. This will probably portend a much slower growth curve for the entire project going forward.
At this point I would be just as happy to have the developers behind the new permissions concepts to simply write some documentation detailing how it is supposed to work and provide a set of use case examples.
Other than that, it is not worth trying to fight with the current system.
BKM
Anyway, I am not trying to fight the current system, I am trying to bring my SAP experience to ERPNext, in the hope to make it better and benifit for others, that is it.
If the focus of the community is on the documentation and internal detailed logic on the current permission system, maybe I can try to research a bit more deeper and contribute this part(documentation).
Very valuable experience indeed!! SAP has been retooling ‘lighter’ versions of itself for the very market that ERPNext is also targeting. They contact me constantly hoping i will recommend their new systems to my clients.
I agree that I would like to see ERPNext move toward a similar set of functions, I just do not know how we get there with currently available developer resources.
Thanks for your experienced input.
BKM
As in the doctype variant discussion thread, Rushahb made it clear any new features from the community can be accepted into the core if it is already validated by customers in production environment and this feature is required by others. for my above listed closed/pending PR, I would like to say at least 70% development work has been done so far, the only problem now is trying to find the potential real customers who has the exact use case/requirement and would like to try new things, take the time to do user acceptance testing and tolerate bugs at initial stages.
I encountered another permission-related problem.
As shown in screenshot below, I am setting the permitted modules for this particular Sales User. Imagine repeating this for every user!
By un-checking Accounting module, this Sales User should not be able to access anything related to Accounting. But as you can see in the next screenshot, this Sales User was able to access to the Chart of Accounts via the Search Bar. All he/she need is to know the correct terms to search, which is fairly easy to find out because he/she can find out everything about ERPNext via internet.
Although he/she couldn’t see any financial numbers in the COA, but still he/she can see all the accounts which supposed to be confidential. In my opinion, any users who do not have permission to any particular modules should NOT be able to search in the Search Bar.
Well, this is another mystery 
I thought modules have nothing to do with permissions, they are only related to desktop icons…
So I always adjust permissions first and then adopt modules, just to align icons a little bit.
Probably I am wrong, but modules are closely related to permissions right? i.e. A Sales staff will have permission to Selling module but he/she should not have permission to Accounts module.
Again this is just my point of view, desktop icons are merely a shortcut to the respective doctype or module right? As I posted above on the issue/bug I encountered, although modules/icons are hidden from a certain users, but they can still access using the search bar.
This is another example I posted which occurs in both v11 and v12: [Serious User Permission Bug] for Sales Manager
