-
Notifications
You must be signed in to change notification settings - Fork 798
Clarify Manageable Roles #11753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: development
Are you sure you want to change the base?
Clarify Manageable Roles #11753
Changes from all commits
efbad28
607f4a1
954cbe6
e79635d
ca6a7ae
07ec41d
420ac8a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -10,56 +10,92 @@ aliases: | |||||||||
|
|
||||||||||
| ## Introduction | ||||||||||
|
|
||||||||||
| A user role aggregates a number of access rights on data, forms, and microflows. An end-user of the application is assigned one or more user roles by an administrator, and gets all access rights that these user roles represent. | ||||||||||
| A user role aggregates a number of access rights to app documents such as data, pages, and microflows. Each end-user of the application is assigned one or more user roles by an end-user with user management rights, and gets all the access rights that these user roles represent. | ||||||||||
|
|
||||||||||
| Every user role has one or more [module roles](/refguide/module-security/#module-role), which means that users with that user role have all the access rights that are defined for those module roles. A typical user role has the **System.User** module role and at least one other module role. | ||||||||||
| Every user role has one or more [module roles](/refguide/module-security/#module-role). End-users with that user role are granted all the access rights defined for those module roles. A typical user role has the **System.User** module role and at least one other module role. | ||||||||||
|
|
||||||||||
| The purpose of the distinction between user roles and module roles is to make a module self-contained (independent from the app in which it is defined or used), so that it can be reused in different apps and/or published to the Marketplace. | ||||||||||
| The separation of user roles and module roles means that modules can be self-contained (independent of the app in which it is defined or used). This allows it to be reused in different apps or published to the Marketplace. | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, that is not what I meant. This is an explanation of why there are user roles and module roles and we don't just put everything into user roles. What I am saying is that having both user roles and module roles means that modules can be self contained. The self-containedness is not a difference between module roles and user roles. |
||||||||||
|
|
||||||||||
| End-users of your application only see the user roles and not the module roles. | ||||||||||
|
|
||||||||||
| To access user roles, open **App Security** > **User roles** tab: | ||||||||||
|
|
||||||||||
| {{< figure src="/attachments/refguide/modeling/security/app-security/user-roles/user-roles-example.png" class="no-border" >}} | ||||||||||
| End-users of your application only see the user roles and not the underlying module roles. | ||||||||||
|
|
||||||||||
| {{% alert color="warning" %}} | ||||||||||
| The effects of changes to user roles are not immediate. This means that your app might show outdated pages or incorrect data. For more information, please refer documentation about [persistent sessions](/refguide/clustered-mendix-runtime/#sessions-are-always-persistent). | ||||||||||
| The effects of changes to user roles are not immediately applied to end-users who are signed in to the app. This means that your app can show the wrong pages or data. Although the user roles are reapplied when their session is revalidated, Mendix advises that end-users sign out and sign in again to pick up their new user roles. This ensures that they have the correct user roles. For more information, refer to the documentation on [persistent sessions](/refguide/clustered-mendix-runtime/#sessions-are-always-persistent). | ||||||||||
|
|
||||||||||
| Mendix recommends that you do NOT use this feature to create a dynamic UI as these changes will not take effect immediately. | ||||||||||
| Mendix recommends that you do NOT use user role changes to create a dynamic UI as these changes do not take effect immediately. | ||||||||||
| {{% /alert %}} | ||||||||||
|
|
||||||||||
| ## User Role Properties | ||||||||||
| ## Managing User Roles | ||||||||||
|
|
||||||||||
| To access user roles, do the following: | ||||||||||
|
|
||||||||||
| Double-click the user role to open its properties. | ||||||||||
| 1. In the App Explorer, go to **App** > **Security**. | ||||||||||
| 1. In the **App Security** dialog, select the **User roles** tab. | ||||||||||
|
|
||||||||||
| The user role has the following properties: | ||||||||||
| {{< figure src="/attachments/refguide/modeling/security/app-security/user-roles/user-roles-example.png" class="no-border" alt="App Security dialog with User roles tab selected, showing Administrator and User roles and their module roles" >}} | ||||||||||
|
|
||||||||||
| * [General properties](#general) | ||||||||||
| * [User management properties](#user-management) | ||||||||||
| 1. Double-click a user role to open its properties. | ||||||||||
|
|
||||||||||
| {{< figure src="/attachments/refguide/modeling/security/app-security/user-roles/user-role-properties.png" class="no-border" >}} | ||||||||||
| The user role properties are split into two sections: | ||||||||||
|
|
||||||||||
| * [General Properties](#general) | ||||||||||
| * [User Management Properties](#user-management) | ||||||||||
|
|
||||||||||
| {{< figure src="/attachments/refguide/modeling/security/app-security/user-roles/user-role-properties.png" class="no-border" alt="User Role 'Administrator' properties dialog showing General and User management sections" >}} | ||||||||||
|
|
||||||||||
| ### General Properties {#general} | ||||||||||
|
|
||||||||||
| General properties of user roles are described in the table below: | ||||||||||
|
|
||||||||||
| | Property | Description | | ||||||||||
| | -------------- | ------------------------------------------------------------ | | ||||||||||
| | Name | The name property defines the name of the user role. This name is shown to end-users who can create or edit user accounts in the application. | | ||||||||||
| | Documentation | In this property you can document additional information about the user role. This information is shown to end-users who can create or edit user accounts in the application. | | ||||||||||
| | Module roles | A list of module roles of which the access rights are accumulated in the user role. An end-user that is assigned a user role gets all access rights of the module roles of that user role. | | ||||||||||
| | Check security | This specifies whether the consistency of security settings is checked for this user role. You can choose to not check security for a user role. For example, user roles that are used only for web service users do not need to be checked because they never sign in to the client. For more information on the security check, see [App Security](/refguide/app-security/). | | ||||||||||
| | Property | Description | | ||||||||||
| | --- | --- | | ||||||||||
| | Name | The name of the user role. This name is shown to end-users who can create or edit user accounts in the application. Blank apps usually start with the **User** and **Administrator** user roles. | | ||||||||||
| | Documentation | Additional information about the user role. This information helps you to assign the correct module roles to each user role. | | ||||||||||
| | Module roles | A list of module roles whose access rights are added to this user role. An end-user that is assigned this user role gets all access rights of the module roles of that user role. | | ||||||||||
| | Check security | Specifies whether Studio Pro checks during development that security settings for this user role are consistent.<br/>You can choose to not check security for a user role. For example, user roles that are used only for web service end-users do not need to be checked because they never sign in to the client. For more information on the security check, see the [Check Security](/refguide/app-security/#check-security) section of *App Security*. | | ||||||||||
|
|
||||||||||
| ### User Management Properties {#user-management} | ||||||||||
|
|
||||||||||
| A user role can be allowed to manage users with a number of other user roles (including itself), called manageable roles. This means that end-users who have this user role, can create, view, edit and delete users with at most the manageable user roles. | ||||||||||
| A user role can be allowed to manage end-users depending on their user roles. These roles are called manageable roles (or grantable roles). | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It gets confusing whose user role we mean here, so I removed it.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is confusing, but it is necessary in this description. What I'm saying is that this user role (UserRole1) can manage end-users but only if they have a manageable role (e.g. UserRole2) - we lose information if we take out "depending on their user roles". How about:
Suggested change
|
||||||||||
|
|
||||||||||
| | Value | Description | | ||||||||||
| | --- | --- | | ||||||||||
| | All | End-users with this user role can manage all users and grant all user roles. Usually this option should only be configured for an administrator. | | ||||||||||
| | Selected | End-users with this user role can manage users that have at most the selected user roles, and can grant only the selected user roles. Select **(No user roles)** to only manage users without a user role (for example, newly created users). If nothing is selected, end-users with this user role cannot manage users at all. | | ||||||||||
| End-users who have this user role can create, view, edit, and delete end-users with the selected roles, provided they do not also have a user role which is not selected. | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No - this user role is not the manageable role, it is the selected roles which are manageable.
Suggested change
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure I understand what "which is not selected" means?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep - this is a mess which is why the next lines give an example 😁 |
||||||||||
|
|
||||||||||
| Take for example an app with three defined user roles: `User`, `Administrator`, and `SubAdministrator`. Assume that you are configuring the `SubAdministrator` user role. The `SubAdministrator` user role has only the `User` user role as a manageable role. | ||||||||||
|
|
||||||||||
| {{< figure src="/attachments/refguide/modeling/security/app-security/user-roles/manageable-roles.png" alt="User management section with only the User role selected as a manageable role" >}} | ||||||||||
|
|
||||||||||
| The following table shows which end-users the `SubAdministrator` user role can manage: | ||||||||||
|
|
||||||||||
| | End-User Name | Has User Roles | SubAdministrator can manage | | ||||||||||
| | --- | --- | --- | | ||||||||||
| | User1 | `User` | Yes¹ | | ||||||||||
| | User2 | `SubAdministrator` | No | | ||||||||||
| | User3 | `User` and `SubAdministrator` | No² | | ||||||||||
|
|
||||||||||
| ¹ The SubAdministrator can only grant or remove the `User` user role. | ||||||||||
| ² Although `User` is a manageable role, User3 also has the `SubAdministrator` user role which is not a manageable role for a SubAdministrator. | ||||||||||
|
|
||||||||||
| The **(No user roles)** manageable role allows this user role to manage end-users without a user role (for example, newly created end-users). | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||
|
|
||||||||||
| The **Select / deselect all** checkbox lets you select all the roles as manageable roles, or deselect them all. | ||||||||||
|
|
||||||||||
| {{% alert color="warning" %}} | ||||||||||
| If the **Select / deselect all** box is checked (that is, all roles are manageable by this user role) then adding a new user role to the app will mean that it is automatically selected as a manageable role. If any of the roles are not selected, then added user roles will not be automatically selected as manageable roles. | ||||||||||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No - that changes the meaning. If any of the roles are not selected then automatic selection is turned off. It only gets automatically selected if all the roles are selected. A terrible UX decision in Mx11 🙄 |
||||||||||
| {{% /alert %}} | ||||||||||
|
|
||||||||||
| {{% alert color="info" %}} | ||||||||||
| Internally, user management properties are translated into implicit entity access rules for **System.User**. This means that they are not applied in microflows that do not check entity access. | ||||||||||
| {{% /alert %}} | ||||||||||
|
|
||||||||||
| ### What Can User Roles Manage? | ||||||||||
|
|
||||||||||
| Users who can manage an end-user can make the following changes: | ||||||||||
|
|
||||||||||
| Internally, user management properties are translated into entity access rules for **System.User**. This means that they are not applied in microflows that do not check entity access. | ||||||||||
| * UserRoles – Grant or remove the selected user roles, but only those user roles which are selected under **User management** | ||||||||||
| * Name | ||||||||||
| * User_TimeZone | ||||||||||
| * Blocked | ||||||||||
| * Active | ||||||||||
| * User_Language | ||||||||||
|
|
||||||||||
| ## Read More | ||||||||||
|
|
||||||||||
|
|
||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to reread the sentence several times to understand it and tried to make it clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That isn't what I meant.
What I mean is that if I am an end-user (Mark) and I have this user role, I am granted access rights from all the module roles which are part of this user role.
A user role is not granted anything - it is just a collection of module roles. It is only when it is manifested as an end-user that it does this.