Populate user types: add user classification method #9952
Conversation
There was a problem hiding this comment.
I think the introduction would improve if starts like:
"In the Mendix Pricing Plan there is a distinction between Internal and External Named Users of a Mendix App. As a customer, you buy a license for a certain amount of internal users and optionally a number of external users (which are typically cheaper. For accurate user metering, external users need to be classified as such. If not classified correctly, your company may exceed the licensed capacity for internal users and Mendix may require you to acquire additional internal user license.
This document helps you to ..."
In this way it is more clear WHY user classification is important and then we switch to the HOW, which is what page is about.
There was a problem hiding this comment.
In the intro there is a sentence that says:
"It describes a sample solution"
With this update we describe multiple solutions so we need to reword.
| @@ -22,30 +22,12 @@ In your Mendix Pricing Plan there is a distinction between Internal and External | |||
|
|
|||
| ## Background | |||
|
|
|||
| Every Mendix app has a system module containing an entity `UserReportInfo`. This entity has an attribute `UserType` that is used to classify end-users as External or Internal Users. This attribute needs to be maintained for all existing and new end-users of a Mendix app. If this attribute is not set, the end-user is classified as an Internal User. | |||
| Every Mendix app has a system module containing an entity `UserReportInfo`. This entity has an attribute `UserType` that is used to classify end-users as `External` or `Internal` Users. This attribute needs to be maintained for all existing and new end-users of a Mendix app. If this attribute is not set, the end-user is classified as an Internal User. | |||
There was a problem hiding this comment.
"needs to be maintained" - passive form, which always brings risk of ambiguity.
Maybe:
"Your application needs to set the attribute for all existing and new (external) end-users. If your application does not set this attribute, the end-user is classified as an Internal User."
| @@ -22,30 +22,12 @@ In your Mendix Pricing Plan there is a distinction between Internal and External | |||
|
|
|||
| ## Background | |||
|
|
|||
| Every Mendix app has a system module containing an entity `UserReportInfo`. This entity has an attribute `UserType` that is used to classify end-users as External or Internal Users. This attribute needs to be maintained for all existing and new end-users of a Mendix app. If this attribute is not set, the end-user is classified as an Internal User. | |||
| Every Mendix app has a system module containing an entity `UserReportInfo`. This entity has an attribute `UserType` that is used to classify end-users as `External` or `Internal` Users. This attribute needs to be maintained for all existing and new end-users of a Mendix app. If this attribute is not set, the end-user is classified as an Internal User. | |||
|
|
|||
| The *Mendix Metering* module relies on this attribute to ascertain the end-user type and report it back to us. | |||
There was a problem hiding this comment.
Mendix metering platform service - it's not a module.
|
|
||
| The *Mendix Metering* module relies on this attribute to ascertain the end-user type and report it back to us. | ||
|
|
||
| {{< figure src="/attachments/deployment/general/populate-user-type/user-type-enumeration.png" class="no-border" >}} | ||
|
|
||
| ## Assigning UserType for Existing Users of IAM Modules |
There was a problem hiding this comment.
As a reader I would want to get an overview first of the avaliable options.
These options should be presented in an outside-in manner, rather than inside-out.
As per my comments on previous PR, we offer following options:
(1) IdP-based. Benefit of this approach is that it may only require configuration of the IAM modules you're using already and no changes in your app model may be needed.
(2) Userrole based. This approach will most likely work for your app, assuming your app has distinct userroles for external versus internal users. Mendix offers the User classification module, which aims at minimizing the development impact for your applications to implement userrole-based user classification.
(3) custom. If you require a different logic than (1) and (2), you have the option to develop custom logic. The User classification module provides logic to minimize impact, but you can also build the entire user classificaytion logic yourself.
(3a) custom using User classification
(3b) custom using your own microflows
Subsequently we should have section explaining these options in same order in more detail .
| @@ -63,7 +45,7 @@ Therefore, the approach we take is to create a new non-persistable entity, `User | |||
|
|
|||
| {{< figure src="/attachments/deployment/general/populate-user-type/usertypereport-properties.png" class="no-border" >}} | |||
|
|
|||
| ### Populating **UserType** for Existing Users of an App {#using-microflow} | |||
| ### Populating `UserType` for Existing Users of an App {#using-microflow} | |||
There was a problem hiding this comment.
I suggest to rename this as "Custom classification logic using your own micfroflow".
There was a problem hiding this comment.
This is (3b), so I also suggest moving this down after next sections, as per my previous remark.
|
|
||
| For more information, see the [Role-based Classification](/appstore/modules/user-classification/#role-based-classification) section of *User Classification*. | ||
|
|
||
| ## Assigning `UserType` for Existing Users of IAM Modules |
There was a problem hiding this comment.
This section should be renamed as "IdP-based user classification".
There was a problem hiding this comment.
This section should be presented as first option; it should go up.
|
|
||
| ## Assigning `UserType` for Existing Users of IAM Modules | ||
|
|
||
| The simplest method to set the user type is by using the Identity and Access Management (IAM) modules, which require only configuration without the need to develop a microflow. Mendix offers you the following IAM modules: |
There was a problem hiding this comment.
I suggest to add a list of prerequisites for IdP-based user classification:
- using on SAML / OIDC / SCIM (including version info - Mendix versions and module versions)
- distinct IdPs External versus internal users.
Note that it may be possible to set-up tow connections between your IdP and your app. In your IdP your app would be seen as two different clients/services. In your app each connection would be seen as a distinct IdP with different configs. - classification of user happens when they login. if correct classification is time-critical you need to assess whther your external users will (all) login before the limits of your 'user buckets' is reached.
| * [SCIM](/appstore/modules/scim/#user-provisioning) | ||
| * [SAML](/appstore/modules/saml/#custom-provisioning-rt) | ||
|
|
||
| ## Assigning `UserTypes` Using Custom logic |
There was a problem hiding this comment.
This is section (3a), right?
I'm refering to my previous suggestion
|
|
||
| {{< figure src="/attachments/deployment/general/populate-user-type/user-type-report.png" class="no-border" >}} | ||
|
|
||
| 7. The report can be exported into an Excel file. | ||
|
|
||
| ## Assigning `UserType` based on User roles | ||
|
|
There was a problem hiding this comment.
Prequisite for this method is:
- distinct userroles for external and internal users
- Include user classification module in your app model. So your app needs to be at least on Mendix 9 LTS or Mendix 10 TLS or Mendix 11
Based on comment: #9921