Documentation:AccessGroups, InterestGroups and ViewModel-Enable

This article describe new features introduced in January 2024

The basic AccessGroups overview is found here

This article has an accompanying sample found here https://github.com/supportMDriven/Samples/tree/master/AccessGroupsInterestGroupsAndViewModelReadOnly

An AccessGroup is a collection of a Enable, Visible and View-Enable expressions. The expression are not rooted - meaning they have no particular context like a user or anything, to get the context of the current user that is very common for AccessGroups one could simply use SysSingleton.oclSingleton.CurrentUser from the SysUserAuthentication-pattern described here

The InterestGroup - the clutter reducer

What differs an InterestGroup from an AccessGroup: The InterestGroup is a softer sibling to the AccessGroup. The AccessGroup is used to control if Access is granted - and this has precedence. The InterestGroup is evaluated after AccessGroups - and controls if we should bother to show the tagged action to the user or not. In a large system the left-side menu can be filled with Class-Actions and ViewModel-Actions, and a user from the SalesDepartment my not be interested in actions leading to views or having functionality specific to the Supply department - or vice versa.

To avoid clutter and confusing options you can tag your users , or have your users tag themselves in a way that you pick up on in an interestgroup. This way users can reduce clutter of left-side menu themselves. If the action is Visible-true for any InterestGroup that tags the action - the action will be visible - but only if any AccessGroups on the action also agrees that it should be visible.

Since the whole point of an InterestGroup is to reduce clutter - the InterestGroup only offer the VisibleExpression - either tagged actions should show or not.

A particular user may be interested in both Sales and Supply and as such the user should get Visible=true for both these interestGroups - and will thus show actions tagged with any of these groups.

A particular action may always be interesting to both Sales and Supply departments and as such it can be tagged with both interestGroups - or no interestGroup. Until you introduce a third group for example the Quality-department that will the same. Having no groups or all groups tagged on an action will be equivalent if all users get Visible=true from at least one InterestGroup.

The View-Enable expression - the extreme complexity reduced to almost nothing

The View-Enable expression has been available on the AccessGroups for some time - but it was a bit clumsy as it knocked out all fields on the tagged View when in evaluated to Enable=false.

This was good for some use-cases, like protecting strict data entry forms - but bad in many cases since many views are not 100% data capture. Most views make use of some local variables - or maybe they change something transient - like an object of a Class marked Persistent=false. And in these cases we really want the user to be able to change the local variabels - but not allowing them to change anything that will need a save to the database (anything marked being persistent=true as is default on classes, attributes and associations).