Changing Security of Marketplace Module

0
I'm faced with a seemingly impossible decision.     An issue related to entity access security was found in a marketplace module that I use for managing users.  As a remediation, we were asked to update the module to a version that includes the XPath constraint '[id = '[%CurrentUser%]']' on our specialized Account entity for a low-level module role also called User.   This would be just fine were it not for some Account entity reference selectors that should bring up a list of all users of a certain App role.   It gets this list of selectable objects from a microflow data source, shown below:  The security update has forced Mendix to bring up an empty list, since Accounts now do not have read access to the attributes of any other Accounts except themselves.   I can just as easily add in another entity access rule that remedies this, but then I'm waiting for a breaking change once I update the marketplace module.  What would be the proper way to maintain security while at the same time keep my app functional?     So far, my only idea is to have 2 reference selectors.  Both would have a condition for visibility based on the footage type.  Each reference selector would then have a different xpath constraint, one for lieutenants and the other for approvers.  This seems like a messy approach.  I would prefer to keep all the logic inside of the microflow if I can.
asked
1 answers
0

You run into this trouble-area because you are looking for two separate lists of persons but you are retrieving these from an Account entity which should only hold user-account information, but also holds person-information. Account entity has access-rules that are meant to keep useraccounts secure. Users are not allowed to see account-information. But in this microflow you want to see the person-information, stored in the same entity. So, there is no option to solve this using associations or access-rules.

My advice is to modify your domain model. Split your person-information from System.User or any specialization thereof. And if you want to store any Lieutent-specific information or Approver-specific information, they will need their own entity too, each associated to the Person entity. This will give you a more explicit and correct data-model, which always helps apps to stay maintainable.

If you choose not to do that, then there is the OQL-option. This will totally bypass any access-rule. Just download and install module OQL and copy-paste the java-action "ExecuteOQLStatement" twice to this microflow. Careful though: OQL gets you copies of the account-objects, not the actual objects themselves. With some unexpected behavior when changing and commiting the retrieved objects. But it might help you out for this microflow.

Best of luck!

 

answered