You can use AccessGroups to control what users may see or edit, InterestGroups to hide actions that are not relevant to a user's current focus, and View-Enable to make persistent data read-only while leaving transient UI work available.

Purpose and scope

This page describes the AccessGroup, InterestGroup, and View-Enable behavior introduced and refined in January–February 2024. For the general AccessGroup model and access-control design, see Documentation:Access groups, Training:Security, and Training:Access control system in MDriven.

An AccessGroup is a reusable collection of expressions that control whether its tagged actions and ViewModels are enabled, visible, or editable. An InterestGroup is an AccessGroup configured to reduce UI clutter: it controls only whether tagged actions are visible. A View-Enable expression is the AccessGroup expression that controls editing on a tagged ViewModel.

Choose the right mechanism

Requirement	Use	Example
Prevent a user from opening, seeing, or executing functionality	AccessGroup	Put administrative actions in a MustBeAdmin group whose expressions test whether the current user is an administrator.
Hide relevant-but-optional actions from a large action menu	InterestGroup	Let a user who is focused on Sales see Sales actions and hide Supply actions.
Allow search criteria, navigation, and other transient UI changes while preventing persisted changes	View-Enable expression	Make a Seeker read-only for persisted data while still allowing the user to enter search criteria and run a search.
Decide whether a particular ViewModel instance may be shown from its root object	AccessExpression	Show a customer ViewModel only when the current root object meets the model-specific access rule.

Configure an AccessGroup

AccessGroup expressions are unrooted. They do not have a ViewModel root object or an action root object. Put user and application context in a model location that the expression can reach.

A common pattern is a singleton that points to the current user. The security training describes the SysSingleton pattern and the oclSingleton operator. For example, an expression can test a property on the current user:

SysSingleton.oclSingleton.CurrentUser.IsAdmin = true

1. Open the AccessGroups editor in MDriven Designer.
2. Create an AccessGroup, for example MustBeAdmin.
3. Define Boolean Enable and Visible expressions for the group. Define a View-Enable expression when the group must control editing on ViewModels.
4. Add the actions and ViewModels that the group controls.
5. Run the application with a user for whom the expression is false and verify both the visible and enabled states.

Keep authorization rules in AccessGroups rather than placing role checks in every action's ordinary enable expression. Ordinary action enable expressions remain available for state-dependent rules, such as enabling Approve only when an order is pending.

Multiple AccessGroups on one action

An action can belong to more than one AccessGroup. AccessGroup membership is additive: if any attached group enables or makes the action visible, that result is combined with the action's own condition.

For an action in Group1, Group2, and Group3:

Enabled = (Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable
Visible = (Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext

For example, an action shared by Sales and Supply can be placed in both departmental AccessGroups. It is enabled when either group grants enable and the action itself is enabled.

Apply a baseline AccessGroup to new views

The RuntimeDefaultOnViews setting on an AccessGroup applies that group at runtime to every view that has no AccessGroups explicitly designed.

Use this for a baseline rule such as IsLoggedIn:

1. Create an AccessGroup whose expressions require a logged-in user.
2. Set RuntimeDefaultOnViews to true.
3. Explicitly assign AccessGroups to views that need their own designed group configuration.

This setting does not add the group to views that already have AccessGroups designed. Review deliberately configured views separately when changing the baseline rule.

Use InterestGroups to reduce action clutter

An InterestGroup is a softer sibling of an AccessGroup. It is intended for user relevance, not authorization.

1. Create or select an AccessGroup.
2. Mark it as an InterestGroup.
3. Define its Visible expression.
4. Tag the actions that belong to that interest.
5. Make the expression evaluate from a user preference or another global model value.

For example, a singleton can hold a Boolean preference named InterestedInSales. A Sales InterestGroup can use that Boolean as its Visible expression. When the user chooses Sales, Sales-tagged actions appear; when the user clears the preference, those actions disappear from the menu.

Evaluation order and visibility rules

AccessGroups are evaluated before InterestGroups. AccessGroups decide whether the user is allowed to see or use an action. InterestGroups are evaluated only when AccessGroups are missing or have produced visible=true; they decide whether the permitted action is worth showing.

An InterestGroup has only a Visible expression. It does not grant enable access and does not control ViewModels. Therefore, an interested user can still see an action disabled, or not see it at all, when an AccessGroup denies visibility.

If an action is tagged with several InterestGroups, it is visible when at least one of those groups evaluates Visible=true, provided AccessGroup evaluation also permits visibility. For example, tag a shared report action with both Sales and Supply so that it appears for a user interested in either area.

An action with no InterestGroups remains outside this interest-based filtering. In a system with only Sales and Supply interests, tagging an action with both groups has the same practical result as leaving it untagged when every user has at least one of those interests enabled. Re-evaluate that choice when you add another interest, such as Quality.

Use View-Enable for safe read-only behavior

Attach an AccessGroup to a ViewModel and use its View-Enable expression to control ViewModel editing. In MDriven Designer, use the button with three dots at the end of the ViewModel's AccessGroups label to open the AccessGroups selection and attach the group.

For example, attach an AllowAccess AccessGroup to a form and set its View-Enable expression to:

SysSingleton.oclSingleton.AllowedAccess

When the expression is false, MDriven evaluates the ViewModel's fields, buttons, and ViewModel actions according to whether they can affect persisted data. This improves on the earlier all-or-nothing behavior, where a false View-Enable expression disabled every field on the tagged view.

What remains enabled when View-Enable is false

When View-Enable evaluates false, MDriven locks expressions that are determined to affect persistent data. It leaves expressions that do not affect persistent data available.

This matters on mixed-purpose views. A Seeker can remain usable for entering search criteria and navigating, while a CreateNew action and edits to persistent business data are blocked. A local variable or an object from a class marked Persistent=false can still be changed because it does not require a database save.

View element or action behavior	Result when View-Enable is false	Example
Changes persistent model data	Locked or disabled	Editing a persistent attribute or changing a persistent association.
Creates or deletes a persistent object	Locked or disabled	A Create action for a persistent class.
Changes only transient state	Can remain enabled	Setting a search-text variable used by a Seeker.
Navigates without manipulating data	Can remain enabled	Opening another view without changing model data.

How MDriven detects persistent effects

For an OCL expression, MDriven checks whether the resulting element belongs to the model and is persistent. If it is persistent, the expression is locked when View-Enable is false.

For an action expression, MDriven deems the expression to affect persistent data when it does any of the following:

• Uses Create or Delete for a persistent class.
• Places a persistent class member on the left side of :=, add, insertat, clear, removeat, or remove.
• Uses a method on a persistent class that is not marked IsQuery.

Review custom action expressions against these rules. An action can look harmless in the UI but still change a persistent association or call a non-query method.

Override persistence-effect detection

Use the tagged value WillEffectPersistedDataOverrideValue when the automatic deduction does not describe an expression correctly. This tagged value was introduced on 2024-02-06 and applies to:

• Columns
• ContextAction (ViewModelAction)
• ClassAction

Use an override only after checking whether the expression changes persistent model data. For example, apply it when an expression's actual persistence effect cannot be inferred from the operators or method metadata described above.

Test the combined behavior

Test access, interest, and View-Enable rules as separate concerns and then together.

1. Start the application and open a ViewModel with a View-Enable AccessGroup attached.
2. Set the access condition false. Confirm that persistent fields and actions are read-only or disabled, while transient search inputs and navigation remain available where applicable.
3. Set the access condition true. Confirm that the previously blocked persistent edits and actions become available.
4. Change an InterestGroup preference. Confirm that matching actions appear or disappear.
5. With an interest enabled but access denied, confirm that the action does not become usable merely because the user is interested.

The accompanying sample demonstrates these scenarios. You can also watch the walkthrough to see a View-Enable rule, transient actions, and InterestGroup filtering in use.

See also

• Documentation:Access groups
• Documentation:Restricting data access
• Documentation:AccessExpression
• Training:Security
• Training:Access control system in MDriven