You can use the OCL canAccess operator when an action, report, or other rule must determine whether its current root object is allowed to open a ViewModel.
A ViewModel can have an Access Expression. This OCL expression can use both the current user and the ViewModel root object to decide whether the ViewModel may be shown.
When a ViewModel Access Expression evaluates to false, MDriven looks for a ViewModel named AccessDenied and shows it. If no AccessDenied ViewModel exists, the result is a blank screen. See Training:Access control system in MDriven for the ViewModel-level access behavior.
Use canAccess before navigation when you want the UI to reflect that outcome earlier. For example, use it in an action's Enable expression so that an action is disabled when its current object cannot open the target ViewModel.
Syntax
self.canAccess(<ViewModel name>)The operator is available on an object and returns a Boolean value:
| Expression result | Meaning |
|---|---|
true
|
The object can access the supplied ViewModel according to that ViewModel's Access Expression. |
false
|
The object cannot access the supplied ViewModel. Do not use the object to open the ViewModel or create output based on it. |
The object on the left side is the root object to test. The supplied ViewModel is the ViewModel whose Access Expression is evaluated.
Use a Designer-safe ViewModel reference
Write the ViewModel name through the ViewModels operator:
self.canAccess(User.ViewModels.UserSettings)In this example, self is tested as the root object for the UserSettings ViewModel. Using User.ViewModels.UserSettings lets MDriven Designer notify you if the ViewModel is renamed.
For the complete operator reference, see Documentation:OCLOperators canAccess.
Disable an action that opens a restricted ViewModel
Use canAccess in the action's Enable expression when the action opens a ViewModel for its current object.
For example, an action on a user object opens the UserSettings ViewModel. Set the action Enable expression to:
self.canAccess(User.ViewModels.UserSettings)The action is enabled only when the target ViewModel's Access Expression permits access for that user object. This avoids offering an action that would otherwise lead to AccessDenied or a blank screen.
An action Enable expression controls whether the action is available. It does not replace the ViewModel Access Expression. Keep the Access Expression on the ViewModel: it remains the rule that decides whether the ViewModel can be shown.
Prevent output from an inaccessible ViewModel
Use the same test before creating a report or other result based on a ViewModel and a root object.
For example, before producing output from UserSettings for a user root object, test:
self.canAccess(User.ViewModels.UserSettings)Only continue when the result is true. This keeps output from being created for a ViewModel/root-object combination that its Access Expression does not allow.
Design access rules at the right level
canAccess evaluates a ViewModel's Access Expression. It is most useful when the decision depends on the root object as well as the current user.
| Requirement | Where to define it | Example |
|---|---|---|
| A ViewModel is unavailable for a particular root object | ViewModel Access Expression, then test it with canAccess before navigation
|
A user may open settings only for an allowed user object. |
| The same authorization rule applies to several actions or ViewModels | AccessGroups | Put administrator-only actions and ViewModels in a MustBeAdmin access group.
|
| An individual action needs a more specific availability rule | The action Enable expression | Disable an edit action when the current object is not in a state that permits editing. |
| A field or placed control must not be editable or visible | The widget ReadOnly or Visible expression | Show a control only for the intended user context. |
For an example of an access rule that uses the current user, see Training:Security. For broader guidance on access groups, interest groups, and ViewModel enable behavior, see Documentation:Restricting data access.
When maintaining a larger model, review actions and the ViewModels they open together. An action can be available while its target ViewModel denies access, or a ViewModel can have no assigned access group even though actions leading to it do. Documentation:Model Access Review provides OCL queries for finding these cases.