Hans Karlsen (talk | contribs) No edit summary |
Hans Karlsen (talk | contribs) No edit summary |
||
| Line 7: | Line 7: | ||
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 [[Documentation:Model Examples Old|described here]] | 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 [[Documentation:Model Examples Old|described here]] | ||
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 | 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|Class-Actions]] and [[ViewModel actions|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. | |||
Revision as of 10:03, 15 January 2024
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
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.