You use Access Groups in MDriven Designer to control whether users can see or use actions and ViewModels, while keeping authorization rules separate from ordinary business-state rules.
What Access Groups solve
Applications commonly need different users to have different UI access. For example, a user may be allowed to invoice only when an invoice is ready and when that user has the required role.
Do not put both decisions into the action's ordinary Enable expression:
- The ordinary action Enable expression should describe whether the action is valid for the current data state. For example, an invoice is ready to be invoiced.
- An Access Group should describe whether the current user is allowed to use the action at all. For example, the user is a manager.
This separation also lets you hide functions that a user must never use, rather than showing a permanently disabled action.
Access Group concepts
An Access Group contains expressions that determine access. The expressions are not rooted in a particular object context. When an expression needs the logged-in user, use an appropriate model path to that user. The SysUserAuthentication pattern example uses SysSingleton.oclSingleton.CurrentUser.
| Term | Meaning | Example |
|---|---|---|
| Access Group | A named collection of access expressions that you attach to actions and ViewModels. | Managers determines whether management functions are available.
|
| Enable expression | Determines whether a tagged action may be used, in addition to the action's own business-state Enable expression. | A manager can use ApproveInvoice only when the invoice is also ready for approval.
|
| Visible expression | Determines whether a tagged action or ViewModel is shown. | A non-manager does not see TheAdminInterface.
|
| View-Enable expression | An Access Group expression used when the group is attached to a ViewModel to control the enabled state of ViewModel edit controls. | A user can open a Department view but its edit controls are unavailable for that user's access condition. |
| Interest Group | A visibility-only, user-interest filter for actions. It reduces UI clutter after access has been evaluated; it is not an authorization mechanism. | A Sales user hides Supply actions from the left-side menu. |
Configure an Access Group
- Open the AccessGroups Editor in MDriven Designer.
- Add an Access Group and give it a name that states the access rule, such as
ManagersorIsLoggedIn. - Define the group's Enable expression and Visible expression.
- If the group will control editability on a ViewModel, define its View-Enable expression.
- Add the actions that the group controls, or attach the group from the action's Access Groups association.
- Attach the group to each ViewModel that must have the same access boundary. On a ViewModel, use the button with three dots at the end of the AccessGroups label to open the group selection.
- Run the application and test the UI with users or model states for which the expression evaluates both true and false.
For example, create a Managers group whose expressions evaluate from the current user. Attach it to an ApproveInvoice action and to the management ViewModel that the action opens. A user who does not meet the group rule should not receive the management entry point or its ViewModel as an unprotected alternative route.
How multiple Access Groups combine on an action
An action can belong to more than one Access Group. MDriven combines the groups with OR logic, then applies the action's own condition.
For enablement:
(Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable
For visibility:
(Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext
This means that membership in any qualifying Access Group can grant the group part of the decision. It does not override the action's own Enable condition.
For example, if ApproveInvoice is assigned to both Managers and Finance, a user accepted by either group can pass the access part of the decision. The action remains disabled if its own action.IsEnable condition says that the invoice is not ready.
Use Interest Groups to reduce action clutter
Mark an Access Group as an Interest Group when it represents what the user wants to see rather than what the user is authorized to do.
Interest Groups differ from Access Groups in two important ways:
- They control visibility of actions only. They do not enable actions and do not control ViewModels.
- They are evaluated after Access Groups. An Interest Group can hide an action that access would otherwise permit, but it cannot expose an action that Access Groups deny.
An Interest Group has only a Visible expression. If an action is tagged with several Interest Groups, it is visible when any tagged Interest Group evaluates Visible=true, provided its Access Group visibility also allows it.
For example, tag Supply-specific actions with a Supply Interest Group and Sales-specific actions with a Sales Interest Group. A user interested in both can see both sets of actions. A user can also select interests through modelled user settings, such as Boolean attributes on a user-related singleton. Turning off the Supply interest removes those actions from the menu; it does not grant or remove authorization.
Use an Access Group, not an Interest Group, for sensitive functions or any function that must be denied to unauthorized users.
Apply a baseline group to new views
The RuntimeDefaultOnViews setting on an Access Group provides a baseline for ViewModels that have no Access Groups designed. When it is true, that group is assigned at runtime to all such views.
For example, an IsLoggedIn group configured with RuntimeDefaultOnViews can ensure that newly created views without explicit groups still require the baseline logged-in condition. Review explicitly assigned ViewModels separately: this setting applies to views with no designed Access Groups.
Design and review checklist
- Put role- and user-based authorization in Access Groups; keep data-state conditions on the action's ordinary Enable expression.
- Attach access rules consistently to both an action and the ViewModel it opens. Securing only the navigation action can leave a ViewModel without its intended access boundary.
- Use Interest Groups only for optional navigation and menu filtering.
- Test each rule when it evaluates true and false, including actions with multiple groups.
- Review ViewModels with no Access Groups and actions whose groups do not match the ViewModels they navigate to. Documentation:Model Access Review provides OCL and EAL queries for finding these cases.
Access Groups and data access
Access Groups control UI availability and editing behavior. Plan data restrictions as well when sensitive data must be protected. See Documentation:Restricting data access for the available approaches and Documentation:OCLOperators AccessGroupsEnable for the runtime operator used to enable one or more Access Groups.