If you would like to upgrade to a newer long-term support version of Studio Pro, see Moving from Mendix Studio Pro 8 to 9.
Access Rules
Introduction
The access rules of an entity define what a user is allowed to do with objects of the entity. Users can be allowed to create and/or delete objects, and to view and/or edit member values. A member is an attribute or an association of an entity. Furthermore, the set of objects available for viewing, editing, and removing can be limited by means of an XPath constraint.
Every access rule is applicable to one or more module roles. An access rule grants certain access rights to those roles. Rules are additive, which means that if multiple access rules apply to the same module role, all access rights of those rules are combined for that module role.
Access rules are not inherited from an entity’s generalization, the security for every entity is specified explicitly. This means that when adding an access rule to an entity, always make sure that all required XPath constraints are applied.
If the entity has a generalization with access rules defining XPath constraints, these will not apply to its specializations and will therefore not limit its visibility.
Properties
Access rules are defined via entity’s Properties > Access rules, or on the Access rules tab of the entity dialog.
An example of the access rules properties is represented in the image below:
Access rules properties consist of the following sections:
Documentation Section
In Documentation, you can describe the intention of the access rule. This helps to keep access rules comprehensible, especially in the case of non-trivial XPath constraints.
Rule Applies to the Following Module Roles Section
Roles
All module roles are listed, and those to which this access rule applies are checked. All users that have at least one of the checked module roles get the access rights that the rule defines.
Select / Deselect All
You can easily select, or deselect, all module roles using this checkbox.
Access Rights Tab
The Access rights tab allows you to assign rights to users with the selected module roles.
Create and Delete Rights Section
Allow creating new objects
If Allow creating new objects is checked, users are allowed to create new objects of this entity.
Allow deleting existing objects
If Allow deleting existing objects is checked, users are allowed to delete existing objects of this entity.
The set of objects that can be deleted can be limited by using an XPath constraint.
Member Read and Write Rights Section
Member read and write rights define the access rights for every member (attribute or association) of the entity. These access rights indicate whether users are allowed to view and/or edit the member’s value. The set of objects to which these rights apply can be limited by using an XPath constraint.
Value | Description |
---|---|
- | Users are not allowed to view or edit the value of the member. |
Read | Users are allowed to view the value of this member, but cannot edit it. |
Read, Write | Users are allowed to view and edit the value of this member. |
Default rights for new members specifies the rights which are applied to new attributes or associations of this entity.
Set all to allows you to quickly set all the access rights for members to None, Read, or Read, Write.
For example, a customer is allowed to view the discount, but is not allowed to edit it. The access rights for the discount attribute are Read.
XPath Constraint Tab
An XPath constraint can be used to constrain the set of objects to which the access rule applies. If the XPath constraint is empty, the rule applies to all objects of the entity.
For example, the Customer entity is a specialization of the User entity. The Order entity is associated to the Customer entity.
A logged-in customer is allowed to view personal orders, but is not allowed to view the orders of other customers. This is accomplished by using the following XPath constraint in the access rule of the Order entity:
[Module.Order_Customer = '[%CurrentUser%]']
Because of this XPath constraint, the access rule only applies to orders for which the customer is the currently signed-in user.