You can control which ViewModels, actions, and view widgets a signed-in user can see or use by defining server-evaluated OCL access rules in MDriven Designer.
Choose the right access-control level
MDriven access control can address both long-lived permissions, such as membership in a role, and conditions that depend on the current business state. For example, a user in the fisherman role may normally be unable to open a Treasury view, but may be allowed to open it when that user has an approved payment that has not yet been collected.
Use the narrowest level that expresses the requirement.
| Requirement | Configure it on | Example |
|---|---|---|
| Reuse the same permission or visibility rule for many actions | Access Group | Allow members of the fisherman role to use fishing-related actions. |
| Enable an action only when the current data is in the required state | Action Enable expression | Enable Collect payment only while a payment has not been collected. |
| Explain why an unavailable action cannot be used | The action's disabled hint | Tell the user that a payment must be approved before it can be collected. |
| Hide or make one placed control read-only | The widget's Visible and/or ReadOnly expression | Show an approval field only to an approver, while keeping it read-only for other users. |
| Make all controls in a view read-only | The view's ReadOnly expression | Let a user inspect a completed payment but prevent edits. |
| Prevent a ViewModel from being shown | The ViewModel's Access expression | Prevent Treasury from opening for a user without the required access. |
Create reusable Access Groups
An Access Group is a named rule that you associate with actions. Use it for access conditions that would otherwise be repeated across many actions. This keeps permission rules separate from an action's data-state rule.
For example, an Access Group can test whether the logged-in user has the fisherman role:
SysSingleton.oclSingleton.CurrentUser.SysRoles->exists(name='fisherman')Create and apply an Access Group in MDriven Designer:
- Open the Access Groups editor and create a group with a descriptive name, such as Fisherman.
- Define the group's Enable expression and Visible expression as required. Use OCL to refer to the current user and model data.
- Add the actions that the group controls to the Access Group.
- For a ViewModel, open its edit controls and select the group through the button with three dots at the end of the AccessGroups field.
- Run the application with users or conditions that make the expression true and false. Verify both the visible and unavailable states.
An Access Group can have separate expressions for whether its members are enabled and visible. This distinction matters: hide an option when the user should not be presented with it; show it but disable it when the option is relevant and the user needs feedback about why it is unavailable.
Combining groups and action rules
An action can belong to more than one Access Group. For enablement, MDriven evaluates the group results together with the action's own Enable expression:
(Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnableFor visibility, the result is:
(Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContextThis lets you model a rule such as: users in either the Accountant or Manager group may use an action, but only when the payment is approved. Put the role-based rule in Access Groups and the payment-state condition in the action's Enable expression.
For detailed Access Group behavior, including Interest Groups, see Documentation:Access groups. Interest Groups are evaluated after Access Groups and only filter action visibility; use them to reduce UI clutter based on a user's chosen interest, not as a replacement for authorization.
Control actions precisely
Use an action's Enable expression for conditions specific to that action and its current object state. For example, an action may be visible to a permitted user but disabled until a business condition is met.
When an action is disabled, provide a user-facing explanation where the action configuration supports it. For example: Payment must be approved before it can be collected. This makes the unavailable state actionable instead of looking like an error.
Do not use a repeated role check in every action when an Access Group expresses the common rule. Keep the action Enable expression for the action-specific condition, such as whether a record is approved, open, or assigned.
Control widgets and entire views
In a ViewModel view, apply rules to individual placed widgets when different users need different interaction with the same screen:
- Set a widget's Visible expression to remove it from the UI when it should not be shown.
- Set a widget's ReadOnly expression when it may be shown but must not be edited.
For example, an approval-status field can be visible to a user while its editing control is read-only. An approval action can then be visible only to the role that may perform approval.
You can also apply expressions to the whole view:
- The view's ReadOnly expression affects every widget in that view.
- The view's Access expression determines whether the view is shown at all.
Use a whole-view ReadOnly expression for a completed record that users may inspect but not change. Use an Access expression when the user must not open the ViewModel for the supplied root object.
Provide an AccessDenied ViewModel
If a ViewModel's Access expression evaluates to false, MDriven looks for a ViewModel named AccessDenied. If it exists, MDriven shows that ViewModel instead. If it does not exist, the user sees a blank screen.
Create an AccessDenied ViewModel to give users a clear outcome when access is denied. For example, it can tell the user that the requested view is not available for the current user or record. Test the denied path as well as the permitted path; otherwise, a missing AccessDenied ViewModel results in a blank screen.
Before an action opens a ViewModel, test whether that ViewModel is accessible for the current root object with the OCL canAccess(vmname):bool operator. Use the result to disable the action when the target view's Access expression would evaluate to false.
This prevents an action from opening the AccessDenied ViewModel for a root object that the user cannot access. It also prevents reports from being created from a ViewModel and root object that do not satisfy that ViewModel's Access expression.
For example, when an action opens a Treasury ViewModel for a payment, use canAccess in the action's condition so the action is unavailable unless that payment can open Treasury for the current user.
Design and test the rule set
- Identify what is being protected: an action, a field, a complete view, or the ability to navigate to a ViewModel.
- Put shared user or role rules in Access Groups. Put record-state rules on the affected action, widget, or view.
- Decide whether each denied case must be hidden, shown as disabled, or shown as read-only.
- Add a clear disabled hint where a visible action can be unavailable.
- For each ViewModel Access expression, create and test an
AccessDeniedViewModel. - Test with conditions that make each expression both true and false, including the root objects used when actions open views and create reports.
MDriven evaluates these declarative OCL rules on the server. The ViewModel defines the data slice made available for an authorized use case; for the security model and the server-side rationale, see Training:Information security. For a focused comparison of Access Groups, Interest Groups, and ViewModel Enable, see Documentation:Restricting data access.