HowTos:Access Logged In User and Use AccessGroups

Access Logged In User and Use AccessGroups

This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.

You can use the logged-in user in OCL expressions and apply AccessGroups to actions and ViewModels when you need to control what authenticated users can see or use.

Use the current logged-in user

The current user is the user identified by your chosen authentication implementation. In the SysUser authentication pattern, the model exposes that user through a transient (non-persistent) singleton named SysSingleton.

Use oclSingleton to obtain the one SysSingleton instance, then navigate its CurrentUser association:

SysSingleton.oclSingleton.CurrentUser

For example, when an action creates a RentalContract, you can retain the created object in a local variable and set its renter to the logged-in user:

let rc = RentalContract.Create in
  rc.Renter := SysSingleton.oclSingleton.CurrentUser

This pattern gives the new contract the current user as its renter instead of requiring the user to select themselves.

Check whether a user is logged in

Use this expression where a Boolean value is required:

not SysSingleton.oclSingleton.CurrentUser.oclIsUndefined()

If your model uses a different representation for an empty association, use the expression appropriate to that model. The important check is that CurrentUser has a value before you rely on it.

Check a user role or model property

Access rules can navigate from CurrentUser to roles or other model data. For example, a rule based on a SysRoles collection can be written as:

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

In the authentication training model, an administrator rule is:

SysSingleton.oclSingleton.CurrentUser.IsAdmin = true

Use properties and association names that exist in your model. See Training:Security and Documentation:SysSingleton for the model pattern behind SysSingleton and CurrentUser.

Create an AccessGroup

An AccessGroup is a named, reusable set of Boolean expressions that controls access to associated actions and ViewModels. Use an AccessGroup for a rule shared by multiple UI elements, such as “must be logged in” or “must be an administrator.” Keep data-state rules that are specific to one action in that action's own Enable expression.

To create a group that requires sign-in:

In MDriven Designer, open the AccessGroups Editor from the top menu toolbar. It is next to the Actions Editor button.
Add an AccessGroup named IsLoggedIn.
Set its Enable Expression to the logged-in check:

not SysSingleton.oclSingleton.CurrentUser.oclIsUndefined()

Set its Visible Expression to the same expression. A user who is not logged in will then not see associated actions.
Set its View Enable Expression to the same expression when the group must also control whether associated ViewModels are enabled.
Save the model.

For an administrator group, create IsAdministrator and use the following expression for the expressions required by your intended behavior:

SysSingleton.oclSingleton.CurrentUser.IsAdmin = true

Apply the group to actions and ViewModels

An AccessGroup does nothing until you associate it with actions or ViewModels.

Protect an action

Open the action in MDriven Designer.
Add IsLoggedIn in the action's AccessGroups association.
Save and run the application.
Log out and confirm that the action is not visible.
Log in and confirm that the action is visible and can be used, subject to the action's own Enable expression.

For example, add IsLoggedIn to the Create Rental Contract action. When signed out, the action is hidden. When signed in, the action can create a contract and assign Renter from SysSingleton.oclSingleton.CurrentUser.

Protect a ViewModel

Open the ViewModel in the ViewModel Editor.
Click the button with three dots at the end of the AccessGroups field.
Select IsLoggedIn, then save.
Run the application and verify the ViewModel while logged out and while logged in.

For example, apply IsLoggedIn to a CarSeeker ViewModel. A signed-out user cannot access that ViewModel; after login, the ViewModel becomes available.

Understand the result when multiple groups apply

You can associate an action with more than one AccessGroup. For actions, the group results are combined as follows:

(Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable

Visibility is combined as follows:

(Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext

This means that any associated group that allows enablement or visibility can contribute a positive result, but the action's own Enable expression must still allow execution. Do not use an action Enable expression as the only place for a shared role rule; put the shared rule in an AccessGroup and retain the action expression for conditions such as required data or workflow state.

Choose hidden, disabled, or denied behavior

Use the control that matches what you want the user to experience:

Requirement	Where to configure it	Example
Hide an action from users who must not use it	AccessGroup Visible Expression	Hide `Create Rental Contract` when no user is logged in.
Show an action but prevent execution in a particular data state	The action's own Enable expression	Disable a save action until required dates are entered.
Prevent access to a ViewModel	Associate an AccessGroup with the ViewModel; use the ViewModel access controls as required	Allow `AutoFormSysUser` only for administrators.
Explain a denied ViewModel request	Create a ViewModel named `AccessDenied`	Show a message such as “You do not have access to this view.”

When a ViewModel's Access expression evaluates to false, MDriven looks for a ViewModel named AccessDenied. If it finds one, it displays that ViewModel; otherwise, the user sees a blank screen. If an action opens a protected view, check the view's access result before allowing the action to open it. See Training:Access control system in MDriven for this behavior and view-level controls.

Do not confuse AccessGroups with InterestGroups

InterestGroups are for reducing UI clutter, not for granting access. An InterestGroup controls only action visibility and is evaluated after AccessGroups. Use an AccessGroup when the user must be prevented from seeing or using an action or ViewModel; use an InterestGroup when an already-authorized user wants a shorter, more relevant action list.

Test the rule

Test each access rule with at least two users or states:

Run the application while logged out. Confirm that IsLoggedIn-protected actions and ViewModels are unavailable.
Log in. Confirm that the same action or ViewModel is available.
For a role-based group such as IsAdministrator, test with a user for whom IsAdmin is false and then with one for whom it is true.
Navigate directly through the UI to a protected ViewModel. Confirm that denial shows the AccessDenied ViewModel when you have created one.
Test the action's business-state Enable expression separately. A logged-in user may be authorized but the action should still remain disabled when its own data requirements are not met.

Contents