Repository navigation
PMP DRM - #12116
PMP DRM#12116katarzyna-koltun-mx wants to merge 9 commits into
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| ### Platform Roles {#platform-role} | ||
|
|
||
| Platform roles define what a user can do on the platform in general. They are assigned to a user account at creation, and can be edited afterwards. Their scope involves the whole plaform. Having multiple platform roles gives a user all the access rights of every role they hold. |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.AmericanSpelling] Use American English spelling 'afterward' instead of 'afterwards'.
| **Reviewer note:** confirm whether a role named API User ships with the platform or is customer-defined. Note also that [Private Mendix Platform Functionalities - Company Administrators](/private-mendix-platform/reference-guide/admin/company/#user-management) currently presents "API users" as a separate kind of account, and that several of the per-account actions on that page are described as available to "local users only". Both need reconciling with the single-account-kind model as part of this change. | ||
| {{% /alert %}} | ||
|
|
||
| ### Sign-In and Lockout Behavior |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.HeadingTitleCase] Use title case capitalization for 'Sign-In and Lockout Behavior'.
|
|
||
| A group needs resources for its members' roles to act upon. | ||
|
|
||
| **Apps.** An app is owned by exactly one group. Assign or move ownership from the App Management page. Apps created through Mendix Studio Pro are owned by the Mendix root group on creation, so transfer ownership after creation if a different group should own them. See [Assigning the App to a New Owner](/private-mendix-platform/reference-guide/admin/company/#ownership). |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| A group needs resources for its members' roles to act upon. | ||
|
|
||
| **Apps.** An app is owned by exactly one group. Assign or move ownership from the App Management page. Apps created through Mendix Studio Pro are owned by the Mendix root group on creation, so transfer ownership after creation if a different group should own them. See [Assigning the App to a New Owner](/private-mendix-platform/reference-guide/admin/company/#ownership). |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| ### Platform Roles | ||
|
|
||
| A Platform Role answers the question *what can this person do on the platform in general?* It is assigned to a user account when the account is created, and can be changed at any time afterwards. Platform Roles are stackable: a user can hold several, and the effective set of permissions is simply everything those roles grant, added together. |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.AmericanSpelling] Use American English spelling 'afterward' instead of 'afterwards'.
|
|
||
| ### Owner | ||
|
|
||
| The user who created the app becomes its owner automatically, and ownership cannot be assigned as a role. The owner has full control of the app, including inviting members, assigning their roles, and transferring ownership. Apps created through Mendix Studio Pro are owned by the Mendix root group on creation, so ask an administrator to transfer ownership if it should sit elsewhere. |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| If you hold Developer or Operator on an app and deployment is nevertheless unavailable, the likely cause is a missing namespace association rather than a role problem. Ask an administrator to confirm that the group owning the app is directly associated with the target namespace. See [Associating Resources with a Group](/private-mendix-platform/access-administration/#associating-resources-with-a-group). | ||
|
|
||
| ## Finding Your Group's Apps and Content |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| ## Finding Your Group's Apps and Content | ||
|
|
||
| Apps owned by groups you belong to are listed on the **My Group Apps** page. See [My Group Apps](/private-mendix-platform/reference-guide/common/group-apps/). |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| ## Finding Your Group's Apps and Content | ||
|
|
||
| Apps owned by groups you belong to are listed on the **My Group Apps** page. See [My Group Apps](/private-mendix-platform/reference-guide/common/group-apps/). |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| ## Finding Your Group's Apps and Content | ||
|
|
||
| Apps owned by groups you belong to are listed on the **My Group Apps** page. See [My Group Apps](/private-mendix-platform/reference-guide/common/group-apps/). |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| To create an account, click **New** and provide the user's name and email address, then assign the Platform Roles the account requires. An account with no Platform Role cannot use the platform, so at minimum assign **User**. | ||
|
|
||
| By clicking **More Actions** by an existing account you can: |
There was a problem hiding this comment.
confirm which of the actions are unavailable for accounts that authenticate through an identity provider. The current Company Administrators page marks several of them "local users only", which reads as an account-type restriction; the list needs restating in terms of authentication method.
|
|
||
| ## Auditing Access Changes | ||
|
|
||
| Changes to user accounts are recorded in the platform activity log, along with app creation and deletion, package creation, and platform setting changes. Retention and logging level are configurable, and expired entries can be downloaded from the archive for audit purposes. See [Activity Logs](/private-mendix-platform/reference-guide/admin/company/#activity-logs). |
There was a problem hiding this comment.
confirm which access-management events are captured in the activity log - specifically whether role edits, group membership changes, and namespace associations are logged, or only account changes.
|
|
||
| ### Automating Group Assignment {#automating-group-assignment} | ||
|
|
||
| **Automation Settings** on the Group Management page lets group membership follow the identity provider information mapped onto users' profiles, rather than being assigned by hand. |
There was a problem hiding this comment.
supply the exact field labels in Automation Settings, which profile attributes can be used, where a newly created group is placed in the hierarchy, and what role its members receive.
|
|
||
| ### Creating a Custom Role | ||
|
|
||
| Click **New** in the relevant tab, name the role, and select its permissions. Choose which system you are creating in deliberately: a role that should let someone administer part of the platform belongs in Platform Roles, and a role that should let someone act on apps and namespaces belongs in Resource Roles. |
There was a problem hiding this comment.
supply the individual permission labels in both schemas, and screenshots of the two tabs. A full role-to-permission matrix should be added to Access Model and Role Reference for Private Mendix Platform and cross-referenced from here.
|
|
||
| A service that calls the platform API signs in as an ordinary account, and what it can do is determined by that account's Platform Role. A role such as **API User**, carrying only the permissions one integration needs, is an example of a Platform Role defined for this purpose. | ||
|
|
||
| Give each integration its own account and its own narrowly scoped role rather than reusing an administrator account. Because the account is ordinary, everything else on this page applies to it: it can be blocked, its roles can be changed, and its actions appear in the activity log. |
There was a problem hiding this comment.
confirm whether a role named API User ships with the platform or is customer-defined. Note also that Private Mendix Platform Functionalities - Company Administrators currently presents "API users" as a separate kind of account, and that several of the per-account actions on that page are described as available to "local users only". Both need reconciling with the single-account-kind model as part of this change.
|
|
||
| A group needs resources for its members' roles to act upon. | ||
|
|
||
| #### Apps |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| #### Apps | ||
|
|
||
| An app is owned by exactly one group. Assign or move ownership from the App Management page. Apps created through Mendix Studio Pro are owned by the Mendix root group on creation, so transfer ownership after creation if a different group should own them. See [Assigning the App to a New Owner](/private-mendix-platform/reference-guide/admin/company/#ownership). |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.ProductNames] Use 'Projects' instead of 'Apps'
|
|
||
| ### Platform Roles | ||
|
|
||
| A platform role answers the question *what can this person do on the platform in general?* It is assigned to a user account when the account is created, and can be changed at any time afterwards. Platform roles are stackable: a user can hold several, and the effective set of permissions is simply everything those roles grant, added together. |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.AmericanSpelling] Use American English spelling 'afterward' instead of 'afterwards'.
| When users sign in through your identity provider rather than with a local account, they still need a place in the group hierarchy and a Resource Role in order to do anything. Three settings determine what happens on first arrival. | ||
|
|
||
| * **Default Group and Default Role.** Every incoming user with no other placement is put into a configured group with a configured role. Pointing these at a deliberately low-privilege landing group gives new arrivals somewhere to be that has no access to real projects, until they are assigned to their actual team. | ||
| * **Parse Roles.** When enabled, Private Mendix Platform reads group and role claims from the incoming token and maps them onto platform roles and groups automatically. When disabled, no such mapping occurs and every federated user lands on the defaults above, to be assigned afterwards manually, through SCIM, or through the platform API. |
There was a problem hiding this comment.
🚫 [vale] reported by reviewdog 🐶
[Mendix.AmericanSpelling] Use American English spelling 'afterward' instead of 'afterwards'.
No description provided.