You can control which ViewModels, actions, and widgets a user can see or use by combining Access Groups, Interest Groups, and ViewModel or action enable expressions.

Choose the right control

MDriven access control targets the interaction points that users work with: ViewModels and actions. Use the control that matches the requirement.

Requirement	Use	Example
A rule applies to many features and depends on the logged-in user's role.	Access Group	Users in the fisherman role may open the Treasury ViewModel.
A feature is relevant to some users but you want to keep navigation less crowded for others.	Interest Group	Show a reporting entry in the left-side menu only to users interested in reporting.
A feature is available in principle, but cannot be used for the current data state.	Enable expression	Disable a Pay action until an invoice is approved.
A user may open a ViewModel but must not edit a particular field or any field in the view.	ReadOnly expression	Let a user inspect a Department but prevent changes.
A user must not open a ViewModel at all.	View Access expression	Prevent users without Treasury access from opening the Treasury ViewModel.

Do not use an action Enable expression as the primary replacement for a role-based rule. An Enable expression is also needed for normal data-state rules. Put reusable, user-based authorization rules in an Access Group and retain the action Enable expression for the current business condition.

Access Groups

An Access Group is a named rule that consolidates an authorization condition used by one or more ViewModels or actions. It is suited to static user-oriented rules, such as whether the current user belongs to a role.

For example, an Access Group for fishermen can use this OCL expression:

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

This expression is true when the current user has a role named fisherman.

Create and apply an Access Group

1. In MDriven Designer, open the AccessGroups Editor.
2. Create an Access Group and define its OCL condition. For example, create Fisherman with the role check shown above.
3. Open the ViewModel that you want to control.
4. At the end of the AccessGroups label, select the ... button to open the Access Groups view.
5. Select the Access Group that controls the ViewModel or action.
6. Run the application and sign in or test with users that meet and do not meet the group condition. Confirm that the controlled feature is available only when the Access Group evaluates to true.

Use AccessGroupsEnabled when you need to enable one or more Access Groups at runtime.

Combine an Access Group with an action rule

An Access Group answers whether a category of user may use a feature. An action Enable expression answers whether the action is valid now.

For example:

• The Accountant Access Group determines whether a user is permitted to use an invoice payment action.
• The action Enable expression determines whether the selected invoice has been approved.

This separation makes the authorization rule reusable and keeps the business-state rule visible on the action.

Interest Groups

An Interest Group controls visibility of a tagged action. Interest Groups are evaluated after Access Groups.

Use an Interest Group when the feature is allowed but is not relevant to every user. This is particularly useful for reducing clutter in the left-side menu. For example, users who are allowed to use reporting can have reporting navigation hidden when they have not selected reporting as an interest.

An Interest Group does not replace an Access Group:

• Access Group: controls whether the user may be shown or use the tagged action.
• Interest Group: controls visibility after Access Group evaluation.

If a feature must be protected from unauthorized users, define the authorization rule with an Access Group or a ViewModel Access expression. Use Interest Groups only for relevance and navigation visibility.

Enable expressions

An Enable expression is an OCL expression that determines whether an action can be executed. A false result leaves the action unavailable rather than treating it as a role-based authorization rule.

For a ViewModel, use the View Enable Expression in the ViewModel edit controls when the whole ViewModel must be enabled only under a condition. For an action, set its Enable expression when only that action depends on the current data.

For example, if a singleton class contains Boolean attributes AllowedAccess and Interested:

• Use AllowedAccess in an Access Group condition when it represents whether the current user is authorized.
• Use Interested for an Interest Group when it represents whether the user wants to see an optional feature.
• Use an Enable expression when the action must be unavailable until the relevant object reaches the required state.

Give users a reason when an action is disabled

When an action is visible but disabled, provide a user-facing explanation where your ViewModel design supports it. For example, explain that payment is unavailable because the invoice is not approved. This distinguishes a temporary business-state restriction from a feature the user is not authorized to use.

Restrict a complete ViewModel or individual widgets

For controls placed in a view, use the widget-level expressions that fit the requirement:

• Visible expression hides a widget.
• ReadOnly expression shows a widget but prevents editing it.

You can also control the complete view:

• A ViewModel-level ReadOnly expression affects all widgets in the view.
• A ViewModel Access expression determines whether the ViewModel is shown at all.

If a ViewModel Access expression evaluates to false, MDriven looks for a ViewModel named AccessDenied. If it exists, MDriven shows it. If it does not exist, the user sees a blank screen.

When an action opens a ViewModel whose Access expression can be false for the current root object, evaluate the same access condition before allowing the opening action. This prevents an action from navigating the user to a denied ViewModel.

Test the result

Test every rule with users and data that produce both true and false results.

1. Test a user who belongs to the required Access Group and a user who does not.
2. Test whether an Interest Group hides optional navigation without becoming the only authorization control.
3. Test action Enable expressions with data that both meets and fails the business condition.
4. Test a denied ViewModel access path. Verify that the AccessDenied ViewModel appears when you have defined one.
5. Test widget-level visibility and read-only behavior separately. A hidden field and a read-only field communicate different things to the user.

Server-side considerations

For server-side execution, an executing ViewModel does not have a logged-in user. Do not configure access rules that only a logged-in user can satisfy when the MDrivenServer must execute that ViewModel. ServerSide actions describes a pattern that uses a Pre EAL value and a separate server access group, while retaining a different group for administrator or developer testing.

Access rules define the approved information slice for an authenticated user. Keep the access-control logic on the server and define the allowed ViewModel data deliberately; see Information security for the underlying security model.

See also

• Documentation:Access groups
• Training:Access control system in MDriven
• Documentation:OCLOperators AccessGroupsEnable
• Documentation:Serverside actions
• Documentation:Part 9 MDriven Turnkey, cloud tools and access groups

Filter the data included in a ViewModel

A ViewModel defines the slice of model data that is shown to an authenticated user who is authorized for a specific use case. MDriven Turnkey performs this reduction from the complete model on the server. The resulting data slice, and changes to it, are then streamed to the client.

Define the ViewModel's information subset declaratively with OCL. Access-control rules can depend on data in the model, including information about the logged-in user and that user's roles or business relationships.

Keep record filtering separate from UI controls

Requirement	Documented control	Effect
Limit the data exposed for an authorized use case.	ViewModel data slice, defined declaratively with OCL.	The server reduces the complete model to the information subset defined by the ViewModel.
Control whether an action or ViewModel is enabled or visible.	Access Group.	Access Groups control enablement and visibility for actions and ViewModels.
Filter optional actions from the UI after Access Group evaluation permits visibility.	Interest Group.	Interest Groups control action visibility and can help declutter the UI.
Control whether a view can be shown.	ViewModel Access expression.	If the expression evaluates to false, MDriven looks for a ViewModel named AccessDenied; if none is found, a blank screen is shown.
Prevent editing or hide a placed widget.	ReadOnly expression and/or Visible expression.	These refine access for widgets placed in a view.

Use the ViewModel data slice when the requirement is to restrict the information exposed to an authenticated user for a use case. Access Groups, Interest Groups, Access expressions, and widget expressions address visibility, enablement, access to a view, or editing behavior at their respective UI levels.

Use the logged-in user in access rules

Where an access rule depends on the logged-in user, model context can be referenced through SysSingleton.oclSingleton.CurrentUser. For example, the training material shows an Access Group expression that tests whether the current user has a role:

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

The specific OCL relationship used to select a ViewModel's permitted records must reflect the application's model and business authorization rules.

See also

• Documentation:Access groups
• Training:Access control system in MDriven
• Training:Information security