You can control which ViewModels, actions, and individual view widgets a signed-in user can see or use by defining declarative OCL rules in your MDriven model.

What access control protects

Access control determines the data and operations available to an authenticated user for a specific use case. In MDriven, the main control points are ViewModels and actions because they define user interaction.

Use access control for both of these cases:

• Static authorization: a rule based on the user's role or group. For example, members of the fisherman role must not open a Treasury ViewModel.
• Dynamic authorization: a rule based on both the user and model data. For example, a fisherman may open Treasury only when that fisherman has been granted a payment that has not yet been collected.

You can also decide whether a user should:

• see an action but be unable to use it;
• not see an action or widget at all; or
• be prevented from opening an entire ViewModel.

MDriven Turnkey evaluates the ViewModel's data reduction and declarative rules on the server. The client receives the resulting permitted slice of data rather than the complete model data. For the security model and server-side rationale, see Training:Information security.

Choose the right control level

Use the narrowest level that expresses the rule.

Requirement	Configure	Example
Reuse the same role-based rule for many actions or ViewModels	An AccessGroup	Only users in the fisherman role can use a set of payment actions.
Allow an action only when the selected object is in a valid state	The action's Enable expression	Enable Collect payment only while the payment is granted and uncollected.
Hide or make one field or control read-only	The placed widget's Visible expression and/or ReadOnly expression	Show a payment amount but prevent editing it for a non-administrator.
Prevent a user from opening a ViewModel for a particular root object	The ViewModel's Access expression	Permit Treasury only for a fisherman whose payment meets the required state.
Make every editable widget in a ViewModel read-only	The ViewModel's Readonly expression	Allow a user to inspect a payment but not change any fields in that view.

Build reusable role rules with AccessGroups

An AccessGroup collects one access rule and applies it to multiple actions and ViewModels. Use it when the rule is repeated, especially for static user-role checks. This keeps access rules in one place instead of copying the same OCL into every action.

For example, if the model makes the signed-in user available through SysSingleton and its CurrentUser association, an AccessGroup rule can test whether the user has the fisherman role:

SysSingleton.oclSingleton.CurrentUser.SysRoles->exists(name='fisherman')

The expression evaluates to true when the current user's SysRoles collection contains a role named fisherman.

1. In MDriven Designer, open the AccessGroups Editor.
2. Create an AccessGroup with a descriptive name, such as MustBeFisherman.
3. Enter an OCL expression that evaluates to true or false.
4. Add the actions and ViewModels that the group controls.
5. Configure the group's enable, visible, and view behavior as required.

AccessGroups can control enablement and visibility for tagged actions and can control access to tagged ViewModels. For detailed editor usage and the distinction from Interest Groups, see Documentation:Access groups and Documentation:Restricting data access.

Use a meaningful current-user model

Your OCL rules need a route to the current user. A common model pattern is a SysSingleton class with a derived CurrentUser association. The singleton expression SysSingleton.oclSingleton returns the singleton instance, creating it when needed. From there, rules can evaluate facts about the current user.

For example, an administrator check can be written as:

SysSingleton.oclSingleton.CurrentUser.IsAdmin=true

See Training:Security for the current-user and singleton pattern.

Control actions

An action's Enable expression controls whether the user can invoke that action. Use it for conditions that depend on the current state, even when the user is authorized to see the action.

For example, a payment-collection action can require both the fisherman role and a payment that has been granted but not collected. The exact attribute names depend on your model, but the rule should express those two conditions.

Keep an action visible but disabled when the action is relevant and you want to communicate that it exists but is not currently available. Hide it when revealing its existence is not appropriate or when it would add unnecessary UI clutter.

When an action is disabled, provide an explanation to the user where your view design supports it. A specific reason, such as “Payment has already been collected,” helps the user correct the condition or understand why the operation is unavailable.

Use an AccessGroup for the common role check and an action Enable expression for the state-specific condition. This avoids duplicating role logic while retaining precise control over each action.

Control fields and other placed widgets

You can refine access within a view at the level of each placed widget.

• Set a widget's ReadOnly expression when the user may see its value but must not edit it.
• Set a widget's Visible expression when the user must not see the widget.

For example, a Treasury view can display a payment amount to a fisherman but make the amount read-only. A separate internal accounting control can be invisible unless the current user is an administrator.

These expressions are appropriate for presentation-level differences within an otherwise accessible ViewModel. They do not replace the ViewModel Access expression when the user must not be allowed to open the ViewModel for a given root object.

Control an entire ViewModel

A ViewModel has two relevant expressions for whole-view behavior:

Expression	Result
Readonly expression	Affects all widgets in the ViewModel, making the view read-only when the expression evaluates to true.
Access expression	Controls whether the ViewModel is shown at all. It can evaluate rules using the current user and the ViewModel's root object.

Use the Access expression for dynamic, object-specific authorization. For example, Treasury can test whether its root payment belongs to the current fisherman and is granted but not collected.

Handle denied access

When a ViewModel's Access expression evaluates to false, MDriven looks for a ViewModel named AccessDenied.

• If AccessDenied exists, MDriven shows that ViewModel.
• If it does not exist, the user sees a blank screen.

Create an AccessDenied ViewModel so that users receive an explicit, useful denied-access experience instead of a blank screen.

Prevent navigation to a denied ViewModel

Do not let an action navigate to a ViewModel that will deny access for its current root object. Test the target ViewModel's Access expression before opening it with the OCL operator canAccess(vmname):bool.

For example, use canAccess in the Enable expression of an action that opens Treasury. When Treasury's Access expression would be false for the current root object, the action is disabled instead of opening the AccessDenied ViewModel.

This also prevents reports from being created from a ViewModel and root object that fail that ViewModel's Access expression.

Recommended design process

1. Identify each user-facing use case and the data that its ViewModel is allowed to expose.
2. Model a route to the current user, such as SysSingleton.oclSingleton.CurrentUser.
3. Create AccessGroups for repeated role-based rules.
4. Add action Enable expressions for state-dependent operations.
5. Add Visible and ReadOnly expressions to individual widgets where a view needs different levels of access.
6. Add a ViewModel Access expression for rules that depend on the root object or that must block the entire view.
7. Create an AccessDenied ViewModel.
8. Use canAccess(vmname):bool on navigation or report actions that target access-controlled ViewModels.
9. Test with users in each role and with root objects in both allowed and denied states.

Keep the authorization rule in model OCL and use the same domain terms that your business and security stakeholders use. This makes the rule inspectable while allowing it to depend on role membership and any relevant data in the model.

See also

• Documentation:Access groups
• Documentation:Restricting data access
• Training:Security
• Training:Information security
• Training:Security concerns for MDriven Server

Enforcement boundary

MDriven Turnkey places its Access Control System on the server. A ViewModel defines the slice of model data to show to an authenticated user who is authorized for a specific use case. According to the security documentation, this reduction from the complete model happens on the server, and the resulting data slice and its changes are streamed to the client.

Access-control rules can be defined declaratively in the model and can depend on data in the model. ViewModels and actions are the targets for access control. For example:

• An action can use an Enable expression to disable the action.
• An AccessGroup can consolidate a rule shared by multiple actions, such as a rule based on whether the current user has a particular role.
• A placed widget can use ReadOnly and Visible expressions.
• A view can use an Access expression. If that expression evaluates to false, the system looks for a ViewModel named AccessDenied; if none is found, a blank screen is shown.

Client and server roles

The client renders the data and user-interface state it receives. The documented security boundary is the server-side Access Control System and server-side ViewModel data reduction, rather than the client presentation.

Client                                             Server
------                                             --------------------------------
UI rendering and interaction                       MDriven Turnkey
                                                   Access Control System
                                                   ViewModel data reduction

request -----------------------------------------> access-control rules and
                                                   permitted ViewModel data slice

permitted data slice and changes <--------------- stream to client

Use visibility, enablement, and read-only settings to present the current state clearly to the user. Keep the access-control rules in the model so that the server-side Access Control System can apply the defined rules when exposing a ViewModel data slice.

See also

• Training:Information security
• Documentation:Restricting data access