You use a ViewModel AccessExpression to allow or deny access to a ViewModel based on its root object; this is for modelers who need object-specific access rules in addition to user-wide Access Groups.

What AccessExpression does

An AccessExpression is a rooted OCL expression on a ViewModel. It must evaluate to true or false.

• true allows the ViewModel to be shown.
• false denies access to the ViewModel.
• An empty AccessExpression defaults to true.

Use AccessExpression when the decision depends on values on the ViewModel's root object. For example, an AccessGroup can decide whether the current user has an administrator role, while an AccessExpression can decide whether that user may open a particular document because of the document's state or owner.

Evaluation order

MDriven evaluates ViewModel access in this order:

1. Access Group evaluation runs first.
2. The ViewModel's AccessExpression runs after the Access Group evaluation.

This means that Access Groups provide the broader, user- or role-oriented rule, and AccessExpression adds a rule for the specific root object being opened.

Rule type	Use it for	Example
Access Group	Rules based on global or logged-in-user information	Only users in an administrator role can access administration ViewModels.
AccessExpression	Rules based on the ViewModel root object's values	A document ViewModel may be opened only when the document belongs to the current user or is in an allowed state.

Configure an AccessExpression

1. Open the ViewModel in MDriven Designer.
2. Select the ViewModel root.
3. Enter an OCL expression in its AccessExpression property.
4. Ensure that the expression returns a Boolean value.
5. Test the ViewModel with both an allowed root object and a denied root object.

For example, if the root object has an owner relationship and the application exposes the logged-in user as SysSingleton.oclSingleton.CurrentUser, an object-specific rule can compare the root object's owner with the current user:

owner = SysSingleton.oclSingleton.CurrentUser

The exact property names in the expression come from your model. Keep the expression focused on access to the current root object, and place reusable role rules in Access Groups.

What the user sees when access is denied

When the AccessExpression evaluates to false, MDriven looks for a ViewModel named AccessDenied.

• If an AccessDenied ViewModel exists, MDriven shows it.
• If no AccessDenied ViewModel exists, the user sees a blank screen.

Create an AccessDenied ViewModel when you want to give users a clear denial message rather than leaving them at a blank screen.

Check access before opening a ViewModel

Use the OCL canAccess(vmname):bool operator when an action needs to determine whether the target ViewModel can be opened for its current root object. This lets you disable or hide an action that would otherwise lead to the AccessDenied ViewModel.

For example, use canAccess in an action's enable expression when that action opens a document ViewModel. If the document does not meet that ViewModel's AccessExpression, the action can be disabled instead of opening a denied view.

This check is also relevant when a report is based on a ViewModel and root object that are not allowed by the ViewModel's AccessExpression.

Design guidance

• Use Access Groups for centralized rules that depend on the logged-in user, roles, or other global state.
• Use AccessExpression for rules that must inspect the particular root object.
• Keep AccessExpression side-effect free. OCL is a query language and access evaluation must not change data.
• Provide an AccessDenied ViewModel if denied access is an expected user path.
• Use canAccess on actions that open a conditionally accessible ViewModel, so users do not enter a path that will be denied.

Compatibility note

Before 2021-02-01, AccessExpression and AccessGroup.ViewEnableExpression had issues in both WPF and Turnkey. These issues are fixed.

See also

• Documentation:Access groups
• Training:Security
• Training:Access control system in MDriven
• Documentation:OCL Expressions