@Chude_Osiegbu:
thanks for giving a helping hand.
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
For more details you can check the updated source code here