Proper Security setup: option can manage users with at most is more dominant than Xpath constraint. This can enable a user to retrieve all account logins on server if not set with care.
I have the following Model: Account is a specialisation of System.User. I added an association: Account (many) to (one) SAAScustomer. SAAScustomer has an attribute IsInScope (boolean). Security case: LocalAccountsAdmin (security role) should be able to read & write accounts that belong to a SAAScustomer where IsInScope = true. Some overall admin users don't belong to a SAAScustomer, and the LocalAccountsAdmin should not be able to see these. Neither should the LocalAccountsAdmin see accounts where IsInScope = false. I tried several scenarios with an account that only has this LocalAccountsAdmin role. LocalAccountsAdmin has read & write access to the Entity Account with Xpath constraints (see below). There are no other Entity Access rules for the combination Account & LocalAccountsAdmin. FYI LocalAccountsAdmin can manage users with at most User role. Xpath: [Administration.Account_SaasCustomer/Administration.SaasCustomer/IsInScope=true()] Result: user is seeing all accounts without filter in an Account List form, but is seeing account details in an Account_NewEdit form and can edit accounts only if they match the Xpath scope. This behaviour on Account is different from similar settings on other Entities. Example: on SAAScustomer I have for this role the Xpath: [IsInScope=true()] ==> In a SAAScustomer list the user is only seeing the records that are in line with the Xpath rule. Is this normal behaviour? Is there a way I can make this user to list only the accounts he/she should have access to?
If I understand correctly the role LocalAccountsAdmin can manage users with the User role, so this means that users with that role can manage them all, this is intended behavior and not part of the xpath constraint in your domain model.
Sebastiaan van den Broek
Be careful with these access rules, they should always end with '%currentuser%.