V11 refactored the user permission system, simplified the user permission doctype, which makes maintaining record level authorization control more easy. so far so good.
but the current new user permission system can not handle the below basic/typical use case elegantly
use case 1: grant buyer A to create/change purchase order in his own company, also allows him/her to display purchase orders from other company code
Different action(create/change/display) on different restricted records
use case 2: grant sales clerk A to create/change sales order of type(non link field) Maintenance, also allows him/her to display all sales orders in the company assigned
Restrict at record level by non-link field or any selected field(custom field)
use case 3: only allow project member and the project manager to change tasks assigned to this project member, while other project member can not change the task.
Restrict by the logon user’s attribute
use case 4: grant stock keeper to allow him/her to post stock entries to a set of locations these locations does not necessarily to be existed in the system when creating/assigning the role to the user
Restrict record by field value range or wildcard
use case 5: Grant key user A maintain Item master, exclude the sensitive accounting related fields such as price, G/L etc, at the same time allow this user to display the accounting fields
Different actions(create/change/display) on field level
Apply user permission at role level eliminated a lot of confusion, but the If Owner check box(option) still caused a lot of confusion.
SAP’s authorization(permission) control system
Define authorization object for the business object(transaction, in ERPNext the doctype),
1.1 multi authorization objects can be defined per business object, each authorization object control the authorization by selected fields
1.2 typically, each authorization object has at least 2 fields, one is activity(create/change/display) and the other is to be checked field from business object(doc), normally type or org field, in each SAP transaction, e.g for purchase order, these 2 fields are PO Type and purchase organization.
Create role, maintain authorization detail: assign allowed values for all authorizations of the selected authorization objects
2.1 allowed values can be single value , value range(from and to, in SQL term between), or wildcard( in SQL like)
2.2 one authorization object can be added into one role multi times, or can be added into different roles, each authorization object with its assigned authorized values is called one authorization with assigned authorization ID
Assign roles to user
3.1 multi roles can be assigned with validity period (valid from and valid to)
3.2 user’s final authorization is all the assigned authorizations of the roles.
3.3 user’s authorization check is based on cached user’s authorization records, which is auto updated after role assignment or role authorization change. thus it is not needed to log out and login again to refresh the newly changed role assignment or role authorization change
authority-check: when transaction start, clicking the create/change/save button in the form view, click the menu etc
4.1 checking logic is very simple and straight forward: get the current business object(doctype)'s assigned authorization object, check the requested value against available value for each authorization field, for requested value, except the special authorization field action which is derived from the button clicked or the operation launched, the value of other fields is the field content of the current business object(doc), the available(assigned) value for the user is the authorizations derived via all assigned roles, in other word, the requested value is single value, for the available value of the authorization field, there maybe no records, or with one or more matched records, or unmatched records. the available value can be single value, a range(from and to), or wildcard(match all), all authorization field checked OK, then the authorization object check is OK, only all authorization object check OK, the final check is OK, otherwise fail.
4.2 the user’s last authorization check failure will be logged into the table which can be retrieved by the admin for detailed analysis
4.3 it is also possible to activate per user and transaction authority check trace which will log all authority check in detail for deeper diagnose
Here it is my ERPNext version authorization object based new permission system, thoroughly tested on my local server, to be posted as a new PR, ERPNext is a great system, it deserves a more advanced and powerful authorization system as its foundation, any idea? feedback?
any further use cases to be simulated/ covered in this new implementation? welcome feedback and comments, suggestions, as always, if there is enough interests and support on this topic, I can start the pull request then.
Here the related use cases
Ability to see all customers where their name is in the Sales person table (currently there is no way to have restrictions based on child tables)
Ability to see all transactions of customers like SO, DN and Sales Invoices (now I don’t know if this would be possible even if the child tables permissions is also added)
Ability to make new Sales Orders only for those customers who are under their command (where the Sales Person name is linked to the customer).