First we need oblige that the reasons for restricting access can be manifold. It may be as simple as to avoid confusing a user with too many options at the wrong time in the process – or it may be as crucial as to protect highly secretive information getting in the wrong hands. Any practical Access control is probably based on static information as “users belonging to group Fishermen should not have access to view Treasury”, but also dynamic information as “if a Fisherman has been granted payment but not collected it yet then he should be able to open the view Treasury”.

Another aspect is that we sometimes want to show that actions are available – but not enabled to you in this particular moment. And at other times we do not even want to show you that a given action exist in the system. These are all common requirements when dealing with access control. Since MDriven solves all user interaction through ViewModels and Actions it is natural that these are our targets for Access Control.

We can set any expression in the Enable expression of an action – so this is one way to make actions disabled. But if we have a rule that is the same for many actions we may consolidate the rule to an AccessGroup;

The accessgroups are good for the static rules like to check is the logged in user is part of the fisherman group:

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

For actions we can set the Enable expression for more precision:

And we may also want to give the user a hint to why the action is disabled – this abilityhas reduced the support requests a lot in all the projects we have done:

For views we refine the access control per placed widget by setting the ReadOnly expression or/and the Visible expression:

But in views we also have the possibility to work on the whole view: