Test default user groups and roles from the SF

Yes please

Since it is possible to pre-define usergroups from the SF, this would be very helpful in testing the actual allowed capabilities of the group members. 

We definitely see the value in being able to simulate a combination of roles from the Software Factory. Technically, this is quite challenging, however.

When the model is synchronized from the Software Factory to the Intelligent Application Manager, the model is not simply copied 1-to-1.

The model in the Software Factory is optimized for development. Information is not duplicated and conflicting information is automatically resolved using priority hierarchies. For instance, when you turn off the editability of a table, you won't get an error that one of the columns is still editable or that a role allows editing of this table. Turning it off will simply ‘overrule’ the column- and role setting in practice.

While this makes life easier for developers, this behavior also requires a bit of calculation. For instance, to determine whether or not you can view and edit a variant column when starting the application via the Software Factory, the Software Factory needs to perform (something like) the following calculations:

• Load the variant grid access types, if present. Else load the base grid access types.
• Check the editability of the base table (the variant may not exceed this)
• Check the editability of the variant (the grid column may not exceed this)
• Check the base column access type (the variant column may not exceed this)
• Check the variant column access type (the grid column may not exceed this)
• Apply the simulated role table rights, taking into account any limitations above.
• Apply the simulated role column rights, taking into account any limitations above.
• Check to see if there is an all-rights exception and apply if needed.
• Check to see, when this column is a look-up, if the look-up is granted in the role
• Check to see, when this column is hidden, if this column should be unauthorized when it is not in use as:
  • A primary key
  • A conditional layout condition
  • The default sorting
  • A process flow sort- or filter input, given that the process flow is authorized in the same role
  • Display field for breadcrumb, maps, tree, scheduler and such
  • Mapped to scheduler start/end date or maps coordinates
  • Used in a cube field
  • etc.

This is quite calculation-intensive and would not fly in a production environment. So, when synchronizing to IAM a lot of pre-calculations and duplications of information are applied:

• All-rights are turned into actual role rights records.
• Ensure the table variant settings are never exceeding the base table settings
• Ensure the grid variant settings are pre-calculated and are not exceeding the base table settings nor the base column settings.
• Store the actual access type with the role rights, which are calculated per variant, taking into account the base table settings, the role settings and the variant settings
• Perform the unauthorized checks and store them with the role rights
• etc.

This ensures that, when starting from IAM, loading the model for a variant grid column can be done really fast. It only consists of the following kinds of checks:

• Load the variant settings for the grid 
• Determine the set of roles
• Apply the most lenient variant access types for all granted roles

Furthermore, this is then cached by IAM in a way that the runtime components can reuse these calculations for other users with the same set of roles.

This very different nature of data structures in IAM and the Software Factory makes it difficult to deliver on an idea like this one without resulting in unacceptable performance issues or a very restrictive and unintuitive development experience.

We will look into this further - perhaps a redesign of the data structures for roles or calculation and normalization during generation for role-combination simulation may offer some solutions.