User management: Process behind Project Security and Account XPaths interactions?

1
Hi all, I have a question regarding the process behind Project Security and Account XPaths interactions. I am working on an app that has a user role (functional administrator) that does user management for most user roles but not all. The user role they are not allowed to manage is the technical administrator user role. The technical administrator is allowed to manage all users. In my app I have the entities 'User' (in the System module) and 'Account' (in the Administration module), Account inherits from User. Both functional administrator and technical administrator are set as module role Administrator for both the System and Administration modules. In Project Security the technical administrator is set to 'All' for User management. The functional administrator is set to 'Selected' with the technical administrator checkbox not checked (the checkbox for '(No user roles)' is checked). I currently have 102 users in my local test environment, 1 is technical administrator without other user roles, 1 is technical administrator with other user roles, and the other 100 have one or more other user roles, or even no user roles at all (95 have no user roles at all). In the Administration module the Administrator has Full Read, Full Write access to the Account entity. Below are five different XPath constraints and the results I get on the Account_Overview page (that page is just a datagrid with all Accounts, data source XPath). A. No XPath constraint at all: not as entity access, not on the page. Result A: functional administrator sees 102 Accounts (not all information is visible but what I care about here is inclusion in the list), technical administrator sees 102 accounts. B. Entity access XPath [not(System.UserRoles = '[%UserRole_TechnicalAdmin%]')] on the Account entity. Result B: functional administrator sees 100 Accounts, technical administrator sees 102 accounts. C. Entity access XPath [System.UserRoles != '[%UserRole_TechnicalAdmin%]'] on the Account entity. Result C: functional administrator sees 101 Accounts (only the technical administrator without other user roles is not included, the technical administrator with other user roles is included), technical administrator sees 102 accounts. D. Page XPath [not(System.UserRoles = '[%UserRole_TechnicalAdmin%]')] Result D: functional admin can see 102 Accounts, technical admin can see 100 Accounts. E. Page XPath [System.UserRoles != '[%UserRole_TechnicalAdmin%]'] Result E: functional admin can see 5 Accounts, technical admin can see 6 accounts. So I would like to know how Project Security and Account XPaths (entity access and on the page) interact to produce these results.   Thanks in advance for answering.   (actual Modeler version: 7.19.1) (This is part 2 of this question. For the answers to part 1 on the difference between != and not() see: https://community.mendix.com/link/questions/92306 )
asked
2 answers
1

The Project Security determines which user roles you can manage, as in assign to or remove from Accounts.

The Xpath's determine your read/write rights to the Account entity. So, if we look at your data:

A. No XPath constraint at all: not as entity access, not on the page.

No restrictions on Account so you can see everything from the Account entity, but not from the User entity. So this explains why you are seeing all records, but not all attributes. The accounts associated to a userrole which you can't manage won't display User attributes.

B. Entity access XPath [not(System.UserRoles = '[%UserRole_TechnicalAdmin%]')] on the Account entity.

Same as A, except not the Accounts who have an association with TechnicalAdmin UserRole

C. Entity access XPath [System.UserRoles != '[%UserRole_TechnicalAdmin%]'] on the Account entity.

Your own description already explains it. The other account which has an asoc. to TechnicalAdmin and other UserRoles is shown here, which is correct.

D. Page XPath [not(System.UserRoles = '[%UserRole_TechnicalAdmin%]')]

Is this correct? I would expect the same results as B, but here they are the other way around...

E. Page XPath [System.UserRoles != '[%UserRole_TechnicalAdmin%]']

This is a bit of a surprise to me because apparently the page xpath gives you different results compared to the entity access xpath. Apparently all Account objects without any userroles are not shown here.

 

answered
0

After contacting Mendix Support I got the following answer:

“From the forum thread we see that points D and E are unclear. Important is that 'entity access XPath constraints' are always applied, regardless the role of the user. They are applied based on the role of the user. 'Page XPath constraints' are applied on rows if you have access to the members in your XPath constraints.

 

Item D : you are not allowed to access the System.UserRoles member on the Users/Accounts with the technical administrator role. Therefore, it cannot check this, so you will see all 102 accounts. Otherwise you could know which account has the 'technical administrator' role, based on the results on this page. A better example why this is important: show me all employees with a salary > 'some value'. If I don't have rights to see the salary attribute of some employees (my boss for example), based on the results on a page, I can find out what the salary is of my boss. For that reason, this constraint is not applied on the employees where I don't have access to the salary attribute.

 

Item E: the XPath says: give me all Accounts with at least one UserRole which is not 'technical administrator'. There are 6 accounts which has a role other than 'technical administrator'. One of them still has the 'technical administrator' role too, so the functional administrator is not allowed to see if this account has another role. For that reason, he only sees 5 accounts.”

answered