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).
Actually I am the SAP authorization manager 5+ years, and also responsible for external and internal audit on system security and authorization control, I know very deep the SAPâs authorization control mechanism, based on the study so far, I think SAPâs authorization control is more straight forward( easy understanding) and advanced than any other. so I am eager to promote it to be implemented in ERPNext.
Your knowledge contribution is great. Do you have documents on SAPâs authorization object? Then we can study and break down to small parts which then can make continous improvements for Frappe
Here my proof of concept
ââ"refactor user permission system
core concept:requested authorizations(the doc) against assigned authorizations by multi auth objs
How it works
define authorization objects, i.e choose authorization fields
1.1 add the special action field which is mapped to the user operation on the doc, such as New,change, delete, cancel etc
1.2 optionally add other to be auth checked fields, multi fields can be assigned per auth object
1.3 multi fields can be combined using | (OR) operator,
e.g owner|approver allows the user to check leave applications which he is owner or approver
1.4 assign authorizaiton objects to doctype
1.4.1 multi auth objects can be assigned
1.4.2 whether mandatory check can be defined per auth obj and doctype
1.5 optionally auth objects can be assigned to doctype field, only one auth object can be assigned to one doctype field
define roles and main authorizations
2.1 select auth object, select auth field, assign authorized values to the authorization field
2.2 authorized value rules
2.2.1 wild card *, which means full authorization on this field
2.2.2 single fixed value
2.2.3 single partial fixed value with wildcard
2.2.4 single variable value link to user master field, using $user. as prefix
2.2.5 single fixed value for field has descendants, which means it includes all its descendants
2.2.6 fixed value with range, value from and value to
2.3 authorization rule: same key assigned to records of authorization fields of the same auth object
2.3.1 one auth object can be added to the same role multi times
assign roles to user
3.1 multi roles can be assigned to same user
System do authorization check at following point
4.1 bypass the auth check for globally accessed doctype, the checking is not necessary
4.2 auth check when user trigger the operation(action) on the target document
4.2.1 implicit check the relevant doc field by the assigned authorization object
4.3 when user retrieves multi documents for listing view, report view, link field search, trigger the implicit read action,
system translate userâs authorizations into matching/filering condition,add it to the SQL where clause in db_query
4.3.1 implicit apply the matching condition of the linked doc type
use cases:
user can display/edit leave applications which he/her is the owner or approver
Solution: define owner|approver as auth field, maintain $user.name as authorization value to the role
use_case1={âauth_objs_fieldsâ:{âlapâ:
[[âlap_ownerâ,âactâ ],
[âlap_ownerâ,âowner|leave_approverâ]]},
âauthorizationsâ:[
[16,âlap_ownerâ,âactâ, â*â, ââ],
[16,âlap_ownerâ,âowner|leave_approverâ,â$user.nameâ,ââ]],
âdocsâ:[
{âdoctypeâ:âlapâ, âactâ:â03â,âuserâ:âadminâ,âownerâ:âadminâ,âleave_approverâ:âfisherâ},
{âdoctypeâ:âlapâ, âactâ:â03â,âuserâ:âadminâ,âownerâ:âfisherâ,âleave_approverâ:âadminâ}]
}
sales user can display/edit only customers which he is the assigned sales person
Solution: define auth obj for customer and add sales person as auth field, maintain $user.name as authorization value to the role
sales user can display/change only sales transactions for customer which he is the assigned sales person
Solution: define auth obj for customer and add sales person as auth field, maintain $user.name as authorization value to the role
also assign the same auth object for customer to the customer field in relevant sales transaciton doctypes
stock user can create/change/display stock entries of Move-In type, can display stock entries of all types
solution: define type as auth field, create authorizations for the same auth obj,
for 1st authorization, assign create/change to action field, Move-In to type field
for 2nd authorization, assign display to action field, * to type field
ââ"
testing result
What if we added the ability to include constraints and custom activities as shown in the screenshot below? I think we would have effectively achieved everything that SAPâs authorization model achieves while still working in a familiar framework.
Roles could then be combined in Role Profiles (or Composite Roles). The only difference with current implementation of Role profiles would be that there would be a one-to-many relationships between Users and Role Profiles and these assignments would have validity dates
@Chude_Osiegbu,
Thanks for your feedback and new idea, to be frank, I still in favor my current design so far, in my opinion, It is more simple and straight forward, involves less concept, and most importantly, IT is already a proven elegant solution in complicated ERP system(SAP)ă
Instead I would like somebody helping me to summarize all relevant use cases, and preparing the relevant test cases, I myself can focus on refining the solution and codingă
Ok. Will take some time to review it again. I think my main hangup with it is the introduction of a new Authorization Object concept. I think the doctypes already work as authorization objects.
