From 886b70cd81ead0b024c3aa4dc6984ff047db062d Mon Sep 17 00:00:00 2001 From: Arjen Hoekstra Date: Thu, 18 Jun 2026 12:12:51 +0200 Subject: [PATCH 1/5] Clarify System.User access rules --- .../modeling/domain-model/entities/access-rules.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md index eea47df2fdc..2394438e74b 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md @@ -22,10 +22,16 @@ Every entity can have multiple access rules which are applicable to one or more {{% alert color="info" %}} Access rules are not inherited from an entity's [generalization](/refguide/entities/#generalization), because the security for every entity is specified explicitly. So 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. +Note that **System.User** is an exception to this: its built-in access rules do apply to specializations and cannot be overridden by the specialization's own access rules. {{% /alert %}} {{% alert color="warning" %}} -The **System.User** entity has inbuilt access rules where access is given to its attributes if the end-user can manage the role of that User object. Specializations of **System.User** (such as **Administration.Account**) cannot change this access with their own access rules. +The **System.User** entity has built-in platform-enforced access rules that grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. Unlike regular access rules — which are defined per entity and are not inherited from generalizations — these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. + +This means that if you create a specialization of **System.User** (such as **Administration.Account**), any user whose role is configured to manage the role assigned to that User object can read the **System.User** attributes of objects of your specialization, regardless of XPath constraints you define on the specialization entity itself. + +Example: If your application requires limiting managers to only see users in their own department, XPath constraints on the specialization alone are not sufficient to enforce this restriction. The access granted through **System.User**'s built-in rules is controlled by the [User management setting](/refguide/user-roles/#user-management) in **App Security**: a user can read **System.User** attributes of a User object only if their role is configured to manage the role of that object. To limit exposure, configure each user role in **App Security** to manage only the roles it strictly needs — avoid granting broad "manage all roles" permissions unless the use case requires it. + {{% /alert %}} ## Defining Access Rules {#new-editor} From 2634f6572208f21a4d5f3c99fee99d61108df34b Mon Sep 17 00:00:00 2001 From: Arjen Hoekstra Date: Thu, 18 Jun 2026 14:16:38 +0200 Subject: [PATCH 2/5] Add the same changes for Mx9 and 10 --- .../modeling/domain-model/entities/access-rules.md | 7 ++++++- .../modeling/domain-model/entities/access-rules.md | 9 +++++++-- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md index 6129cda5f9d..3a1d95ed779 100644 --- a/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md @@ -22,10 +22,15 @@ Every entity can have multiple access rules which are applicable to one or more {{% alert color="info" %}} Access rules are not inherited from an entity's [generalization](/refguide10/entities/#generalization), because the security for every entity is specified explicitly. So 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. +Note that **System.User** is an exception to this: its built-in access rules do apply to specializations and cannot be overridden by the specialization's own access rules. {{% /alert %}} {{% alert color="warning" %}} -The **System.User** entity has inbuilt access rules where access is given to its attributes if the end-user can manage the role of that User object. Specializations of **System.User** (such as **Administration.Account**) cannot change this access with their own access rules. +The **System.User** entity has built-in platform-enforced access rules that grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. Unlike regular access rules — which are defined per entity and are not inherited from generalizations — these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. + +This means that if you create a specialization of **System.User** (such as **Administration.Account**), any user whose role is configured to manage the role assigned to that User object can read the **System.User** attributes of objects of your specialization, regardless of XPath constraints you define on the specialization entity itself. + +Example: If your application requires limiting managers to only see users in their own department, XPath constraints on the specialization alone are not sufficient to enforce this restriction. The access granted through **System.User**'s built-in rules is controlled by the [User management setting](/refguide10/user-roles/#user-management) in **App Security**: a user can read **System.User** attributes of a User object only if their role is configured to manage the role of that object. To limit exposure, configure each user role in **App Security** to manage only the roles it strictly needs — avoid granting broad "manage all roles" permissions unless the use case requires it. {{% /alert %}} ## Defining Access Rules {#new-editor} diff --git a/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md index 5ae584cb913..d044ac15918 100644 --- a/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md @@ -11,12 +11,17 @@ The access rules of an entity define what a user is allowed to do with objects o Every access rule is applicable to one or more [module roles](/refguide9/module-security/#module-role). 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. -{{% alert color="warning" %}} +{{% alert color="info" %}} Access rules are not inherited from an entity's [generalization](/refguide9/entities/#generalization), because the security for every entity is specified explicitly. So 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. +Note that **System.User** is an exception to this: its built-in access rules do apply to specializations and cannot be overridden by the specialization's own access rules. {{% /alert %}} {{% alert color="warning" %}} -The **System.User** entity has inbuilt access rules where access is given to its attributes if the user can manage the role of that user. Specializations of **System.User** (such as **Administration.Account**) cannot restrict this access with their own access rules. +The **System.User** entity has built-in platform-enforced access rules that grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. Unlike regular access rules — which are defined per entity and are not inherited from generalizations — these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. + +This means that if you create a specialization of **System.User** (such as **Administration.Account**), any user whose role is configured to manage the role assigned to that User object can read the **System.User** attributes of objects of your specialization, regardless of XPath constraints you define on the specialization entity itself. + +Example: If your application requires limiting managers to only see users in their own department, XPath constraints on the specialization alone are not sufficient to enforce this restriction. The access granted through **System.User**'s built-in rules is controlled by the [User management setting](/refguide9/user-roles/#user-management) in **App Security**: a user can read **System.User** attributes of a User object only if their role is configured to manage the role of that object. To limit exposure, configure each user role in **App Security** to manage only the roles it strictly needs — avoid granting broad "manage all roles" permissions unless the use case requires it. {{% /alert %}} ## Defining Access Rules From e779d6f3921c5a6b62d27119fabfbf411460f925 Mon Sep 17 00:00:00 2001 From: MarkvanMents Date: Fri, 19 Jun 2026 13:38:02 +0200 Subject: [PATCH 3/5] Improve clarity of System.User access rules for Mendix 11 Restructured the System.User warning alert to improve readability and logical flow by breaking it into bulleted features and a clearer example. Changed the example paragraph to explicitly state why XPath constraints fail and how User management settings control access. Co-Authored-By: Claude Sonnet 4.5 --- .../domain-model/entities/access-rules.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md index 2394438e74b..19e4f55e817 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md @@ -22,15 +22,22 @@ Every entity can have multiple access rules which are applicable to one or more {{% alert color="info" %}} Access rules are not inherited from an entity's [generalization](/refguide/entities/#generalization), because the security for every entity is specified explicitly. So 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. -Note that **System.User** is an exception to this: its built-in access rules do apply to specializations and cannot be overridden by the specialization's own access rules. {{% /alert %}} {{% alert color="warning" %}} -The **System.User** entity has built-in platform-enforced access rules that grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. Unlike regular access rules — which are defined per entity and are not inherited from generalizations — these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. +The **System.User** entity is a special case when considering access rules. It has the following features: -This means that if you create a specialization of **System.User** (such as **Administration.Account**), any user whose role is configured to manage the role assigned to that User object can read the **System.User** attributes of objects of your specialization, regardless of XPath constraints you define on the specialization entity itself. +* **System.User** has built-in platform-enforced access rules. -Example: If your application requires limiting managers to only see users in their own department, XPath constraints on the specialization alone are not sufficient to enforce this restriction. The access granted through **System.User**'s built-in rules is controlled by the [User management setting](/refguide/user-roles/#user-management) in **App Security**: a user can read **System.User** attributes of a User object only if their role is configured to manage the role of that object. To limit exposure, configure each user role in **App Security** to manage only the roles it strictly needs — avoid granting broad "manage all roles" permissions unless the use case requires it. + These rules grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. + +* **System.User** built-in access rules apply to specializations of **System.User**. + + Unlike regular access rules, which are defined per entity and are not inherited from generalizations, these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. + + This means that if you create a specialization of **System.User** (for example, **Administration.Account**), any user with a role which manages the role assigned to that User object can always read the **System.User** attributes of objects of your specialization. This is the case, even if you add XPath constraints on the specialization entity to prevent this. + +For example, suppose you want to limit managers to only see users in their own department. Using only XPath constraints on the specialization cannot enforce this restriction because the [User management](/refguide/user-roles/#user-management) setting in **App Security** can grant access to **System.User** attributes for any role configured to manage that User object's role. To enforce the department restriction, configure each user role in **App Security** to manage only the roles it strictly needs—avoid granting broad "manage all roles" permissions unless your use case requires it. {{% /alert %}} From d298080273b96c6c6c9227393e346fdec95e3c71 Mon Sep 17 00:00:00 2001 From: MarkvanMents Date: Mon, 22 Jun 2026 11:32:45 +0200 Subject: [PATCH 4/5] Copy changes to Mx9 and Mx10 --- .../domain-model/entities/access-rules.md | 1 - .../domain-model/entities/access-rules.md | 15 +++++++++++---- .../domain-model/entities/access-rules.md | 15 +++++++++++---- 3 files changed, 22 insertions(+), 9 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md index 19e4f55e817..13b681f9f8d 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md @@ -38,7 +38,6 @@ The **System.User** entity is a special case when considering access rules. It h This means that if you create a specialization of **System.User** (for example, **Administration.Account**), any user with a role which manages the role assigned to that User object can always read the **System.User** attributes of objects of your specialization. This is the case, even if you add XPath constraints on the specialization entity to prevent this. For example, suppose you want to limit managers to only see users in their own department. Using only XPath constraints on the specialization cannot enforce this restriction because the [User management](/refguide/user-roles/#user-management) setting in **App Security** can grant access to **System.User** attributes for any role configured to manage that User object's role. To enforce the department restriction, configure each user role in **App Security** to manage only the roles it strictly needs—avoid granting broad "manage all roles" permissions unless your use case requires it. - {{% /alert %}} ## Defining Access Rules {#new-editor} diff --git a/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md index 3a1d95ed779..6cd52931e53 100644 --- a/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide10/modeling/domain-model/entities/access-rules.md @@ -22,15 +22,22 @@ Every entity can have multiple access rules which are applicable to one or more {{% alert color="info" %}} Access rules are not inherited from an entity's [generalization](/refguide10/entities/#generalization), because the security for every entity is specified explicitly. So 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. -Note that **System.User** is an exception to this: its built-in access rules do apply to specializations and cannot be overridden by the specialization's own access rules. {{% /alert %}} {{% alert color="warning" %}} -The **System.User** entity has built-in platform-enforced access rules that grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. Unlike regular access rules — which are defined per entity and are not inherited from generalizations — these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. +The **System.User** entity is a special case when considering access rules. It has the following features: -This means that if you create a specialization of **System.User** (such as **Administration.Account**), any user whose role is configured to manage the role assigned to that User object can read the **System.User** attributes of objects of your specialization, regardless of XPath constraints you define on the specialization entity itself. +* **System.User** has built-in platform-enforced access rules. -Example: If your application requires limiting managers to only see users in their own department, XPath constraints on the specialization alone are not sufficient to enforce this restriction. The access granted through **System.User**'s built-in rules is controlled by the [User management setting](/refguide10/user-roles/#user-management) in **App Security**: a user can read **System.User** attributes of a User object only if their role is configured to manage the role of that object. To limit exposure, configure each user role in **App Security** to manage only the roles it strictly needs — avoid granting broad "manage all roles" permissions unless the use case requires it. + These rules grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. + +* **System.User** built-in access rules apply to specializations of **System.User**. + + Unlike regular access rules, which are defined per entity and are not inherited from generalizations, these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. + + This means that if you create a specialization of **System.User** (for example, **Administration.Account**), any user with a role which manages the role assigned to that User object can always read the **System.User** attributes of objects of your specialization. This is the case, even if you add XPath constraints on the specialization entity to prevent this. + +For example, suppose you want to limit managers to only see users in their own department. Using only XPath constraints on the specialization cannot enforce this restriction because the [User management](/refguide10/user-roles/#user-management) setting in **App Security** can grant access to **System.User** attributes for any role configured to manage that User object's role. To enforce the department restriction, configure each user role in **App Security** to manage only the roles it strictly needs—avoid granting broad "manage all roles" permissions unless your use case requires it. {{% /alert %}} ## Defining Access Rules {#new-editor} diff --git a/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md index d044ac15918..7ef138dd57c 100644 --- a/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide9/modeling/domain-model/entities/access-rules.md @@ -13,15 +13,22 @@ Every access rule is applicable to one or more [module roles](/refguide9/module- {{% alert color="info" %}} Access rules are not inherited from an entity's [generalization](/refguide9/entities/#generalization), because the security for every entity is specified explicitly. So 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. -Note that **System.User** is an exception to this: its built-in access rules do apply to specializations and cannot be overridden by the specialization's own access rules. {{% /alert %}} {{% alert color="warning" %}} -The **System.User** entity has built-in platform-enforced access rules that grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. Unlike regular access rules — which are defined per entity and are not inherited from generalizations — these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. +The **System.User** entity is a special case when considering access rules. It has the following features: -This means that if you create a specialization of **System.User** (such as **Administration.Account**), any user whose role is configured to manage the role assigned to that User object can read the **System.User** attributes of objects of your specialization, regardless of XPath constraints you define on the specialization entity itself. +* **System.User** has built-in platform-enforced access rules. -Example: If your application requires limiting managers to only see users in their own department, XPath constraints on the specialization alone are not sufficient to enforce this restriction. The access granted through **System.User**'s built-in rules is controlled by the [User management setting](/refguide9/user-roles/#user-management) in **App Security**: a user can read **System.User** attributes of a User object only if their role is configured to manage the role of that object. To limit exposure, configure each user role in **App Security** to manage only the roles it strictly needs — avoid granting broad "manage all roles" permissions unless the use case requires it. + These rules grant access to its attributes when the requesting user's role is configured to manage the role assigned to that User object. + +* **System.User** built-in access rules apply to specializations of **System.User**. + + Unlike regular access rules, which are defined per entity and are not inherited from generalizations, these built-in rules operate at the platform level and cannot be overridden or restricted by access rules defined on a specialization. + + This means that if you create a specialization of **System.User** (for example, **Administration.Account**), any user with a role which manages the role assigned to that User object can always read the **System.User** attributes of objects of your specialization. This is the case, even if you add XPath constraints on the specialization entity to prevent this. + +For example, suppose you want to limit managers to only see users in their own department. Using only XPath constraints on the specialization cannot enforce this restriction because the [User management](/refguide9/user-roles/#user-management) setting in **App Security** can grant access to **System.User** attributes for any role configured to manage that User object's role. To enforce the department restriction, configure each user role in **App Security** to manage only the roles it strictly needs—avoid granting broad "manage all roles" permissions unless your use case requires it. {{% /alert %}} ## Defining Access Rules From 94281179bc84e1bd08c3dfa2aee69f5a14cc0e8a Mon Sep 17 00:00:00 2001 From: MarkvanMents Date: Mon, 22 Jun 2026 11:47:37 +0200 Subject: [PATCH 5/5] Proofread --- .../modeling/domain-model/entities/access-rules.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md index 13b681f9f8d..4c1c5dccb1e 100644 --- a/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md +++ b/content/en/docs/refguide/modeling/domain-model/entities/access-rules.md @@ -42,7 +42,7 @@ For example, suppose you want to limit managers to only see users in their own d ## Defining Access Rules {#new-editor} -You can view access rules in the **Access rules** tab of the entity properties dialog. Open this by double clicking on an entity in the domain model. +You can view access rules in the **Access rules** tab of the entity properties dialog. Open this by double clicking an entity in the domain model. {{% alert color="info" %}} The **Access rules** section is only visible if the [App Security](/refguide/app-security/) is set to **Production**. @@ -50,7 +50,7 @@ The **Access rules** section is only visible if the [App Security](/refguide/app ### Editor Layout -The access rules editor displays each access rule belonging to the entity as a column. The header shows the module role(s) the access rules apply to. When the module role name is long or there are multiple roles, you can see only part of the label. Hover over the header to show the full module role(s). +The access rules editor displays each access rule belonging to the entity as a column. The header shows the module roles the access rules apply to. When the module role name is long or there are multiple roles, you can see only part of the label. Hover over the header to show the full module roles. You can add access rules by clicking **New**. @@ -72,9 +72,9 @@ When an access rule has entity rights, this is shown using the **Create** ({{% i In the access rule, access to specific members (attributes or associations belonging to the entity) can be controlled. The access can be **None**, **Read**, or **Read and Write**. When there is no access, no icon is displayed in the row of the member in the access rule column. If there is **Read** access, a **Read** icon ({{% icon name="view" %}}) is displayed. For **Read and Write** access, both the **Read** ({{% icon name="view" %}}) and **Write** ({{% icon name="pencil" %}}) icons are displayed. -### Creating or editing an access rule +### Creating or Editing an Access Rule -Access rules can be created from the **New Access Rule** dialog. This dialog can be opened by clicking **New**. To edit an existing access rule, select an access rule and click **Edit** or double-click on the access rule. +Access rules can be created from the **New Access Rule** dialog. This dialog can be opened by clicking **New**. To edit an existing access rule, select an access rule and click **Edit** or double-click the access rule. {{< figure src="/attachments/refguide/modeling/domain-model/entities/access-rules/access-rule-editor.png" alt="This image indicates the position of the Delete icons" width="550px" class="no-border" >}} @@ -82,13 +82,13 @@ Access rules can be created from the **New Access Rule** dialog. This dialog can You can add documentation to describe the access rule. -#### Module roles +#### Module Roles -Select the module role(s) this access rule applies to. If there are no module roles selected there will be a consistency error. +Select the module roles this access rule applies to. If there are no module roles selected there will be a consistency error. #### XPath Constraints -To edit the XPath constraint, click **Edit...** next to the XPath constraint field. This will open the XPath editor dialogue to edit the XPath constraint of the access rule. +To edit the XPath constraint, click **Edit...** next to the XPath constraint field. This will open the XPath editor dialog to edit the XPath constraint of the access rule. {{% alert color="warning" %}} XPath constraints can only be applied to persistable entities, as they are applied by the database. Defining XPath constraints for non-persistable entities results in consistency errors.