Relative to entity XPath constraints - Mendix Forum

Relative to entity XPath constraints


When defining entity access on database level it would be great if users could restrict the entity access based on a relative entity and it's Xpath constraint.
Currently you often have to traverse back to the “current user” in order to set the appropriate entity access via many associations.

I would like it to be possible to define access on for example [Entity A] with a relative path to current user and then from [Entity A] define the entity access for [Entity B]

It would require being able to set a name in the modeler for the XPath constraint so that you can reference them easily.

For example:

We have a module called Orders with 2 entities:  Entity A = product order with multiple  Entity B = product order line items, so it is a 1-* relationship.

ProductOrder has the XPath constraint [createdBy = '%CurrentUser%’]

We would name that "IsCreator”

ProductOrderLineItem has the XPath constraint [Orders.ProductOrder_ProductOrderLineItem/Orders.ProductOrder/Extend(IsCreator)]

A more complex addition could then be

ProductOrder having an association towards an entity called Recipient in that same module which for the sake of easy explanation is a generalization of system user.

[Orders.ProductOrder_Recipient = '%CurrentUser%’]

Which we would name "IsRecipient”

ProductOrderLineItem now can have the XPath constraint [Orders.ProductOrder_ProductOrderLineItem/Orders.ProductOrder/Extend(IsCreator or IsRecipient)]





1 answers

You got my vote, entity access constraints can be very cumbersome to set up and maintain.

The advanced use cases you describe can be very interesting, but also might add a lot of complexity. At the very least I would like to be able to ‘inherit’ the parent access rules (user is only allowed to see the orderlines if the user also has access to the order). This way, if the rules on the ‘Order’ level change or are extended, the rules on underlying entities will automatically change with them. This makes them easier to maintain and less error-prone..


e.g. rule on orderline could become


instead of

[Orders.Orderline_Order/Orders.Order/createdBy = '%CurrentUser%’]