Access groups
No edit summary
No edit summary
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Access groups are described in several places :
Access groups are described in several places :
* [[Documentation:AccessGroups, InterestGroups and ViewModel-Enable|AccessGroups, InterestGroups and ViewModel-Enable]]
* [[Part 9 MDriven Turnkey, cloud tools and access groups|Part 9 MDriven Turnkey: cloud tools and access groups]]
* [[Turnkey session 5: How to access the logged in user. AccessGroups]]
* [[Training:Access control system in MDriven|Access_control_system_in_MDriven]]
* [[AccessExpression]]
The main purpose of Access Groups is to control what is visible and/or enabled for a user in a certain role or situation.


[[Part 9 MDriven Turnkey, cloud tools and access groups|Part_9_MDriven_Turnkey]],_cloud_tools_and_access_groups
An access group (ag) can be set as an '''Interest group''' (ig). An Interest group acts the same way as an Access group but with these key differences:
# An Interest group only controls the visibility of actions - but access groups control enable and visibility for both actions and ViewModels.
# An Interest group is only evaluated if access groups are either missing or evaluating to visibility true.
The rationale for Interest groups is to segment a large set of actions into different user-chosen interests so that actions can be filtered away from the UI and thus, have users find their way easily.


[[Turnkey session 5: How to access the logged in user. AccessGroups|Turnkey_session_5]]:_How_to_access_the_logged_in_user._AccessGroups
The use of ClassActions can be very productive from a design perspective, but can also bloat UI's with actions that are not really needed in a certain use-case. Prior to interest groups, we needed to [[Turnkey session 3: Opting out actions|opt-out]] these actions on a view-by-view basis. The interest groups make it possible to filter away such actions based on some other criteria - for example, a user-chosen focus.


[[Access_control_system_in_MDriven]]
=== Overview of Access Groups ===
 
[[AccessExpression]]
 
The main purpose of Access Groups are to control what is a visible and/or enabled for a user in a certain role or situation.
 
An access group (ag) can be set as being an Interest group (ig). An Interest group acts the same way as an Access group with these key differences:
# An interest group only control visibility of actions - but access groups control enable and visibility for both actions and viewModels
# An interest group is only evaluation if access groups is either missing of are evaluating to visibility true
The rational for Interest groups is to segment a large set of actions into different user chosen interest - so that actions could be filtered away from the UI so that users find the way easier.
 
The use of ClassActions can be very productive from the design perspective - but can also bloat UI's with actions that are not really needed in a certain use-case. Prior to interest groups we needed to opt-out these actions on a view by view basis. The interest groups makes it possible to filter away such actions based on some other criteria - like for example a user chosen focus.
 
==== Overview of access groups ====
You probably have different users in your system and these users are associated with an access group somehow (ActiveDirectory or something in your application).
You probably have different users in your system and these users are associated with an access group somehow (ActiveDirectory or something in your application).


Line 29: Line 25:
[[File:Access groups - 1.png|frameless|423x423px]]
[[File:Access groups - 1.png|frameless|423x423px]]


Clicking up the AccessGroup dialog shows you this:
Clicking on the AccessGroup dialog shows you this:


[[File:Access groups - 2.png|frameless|423x423px]]
[[File:Access groups - 2.png|frameless|423x423px]]
Line 37: Line 33:
An AccessGroup contains actions - you can add and remove associations.
An AccessGroup contains actions - you can add and remove associations.


If an action is a member of multiple AccessGroups, the result will be;
If an action is a member of multiple AccessGroups, the result will be:
  (Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable
  (Group1.IsEnable OR Group2.IsEnable OR Group3.IsEnable) AND action.IsEnable
And to make the result visible:
And to make the result visible:
  (Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext
  (Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext
  [[Category:Security]]
[[Category:Security]]
{{Edited|July|12|2024}}
[[Category:Access groups]]

Latest revision as of 06:43, 3 April 2024

Access groups are described in several places :

The main purpose of Access Groups is to control what is visible and/or enabled for a user in a certain role or situation.

An access group (ag) can be set as an Interest group (ig). An Interest group acts the same way as an Access group but with these key differences:

  1. An Interest group only controls the visibility of actions - but access groups control enable and visibility for both actions and ViewModels.
  2. An Interest group is only evaluated if access groups are either missing or evaluating to visibility true.

The rationale for Interest groups is to segment a large set of actions into different user-chosen interests so that actions can be filtered away from the UI and thus, have users find their way easily.

The use of ClassActions can be very productive from a design perspective, but can also bloat UI's with actions that are not really needed in a certain use-case. Prior to interest groups, we needed to opt-out these actions on a view-by-view basis. The interest groups make it possible to filter away such actions based on some other criteria - for example, a user-chosen focus.

Overview of Access Groups

You probably have different users in your system and these users are associated with an access group somehow (ActiveDirectory or something in your application).

You will want to allow and disallow user groups to execute actions.

This could be done as enable expressions on the Actions – but that would not be beneficial since it would kidnap the use of enable from the normal things we use enable for (check data state). Also, if a user is never allowed to execute “TheAdminInterface” it might be best to hide that action from view altogether.

To facilitate this, Modlr has a new concept called AccessGroups:

Access groups - 1.png

Clicking on the AccessGroup dialog shows you this:

Access groups - 2.png

Here, you can add groups and define the EnableExpression and VisibleExpression for the AccessGroups.

An AccessGroup contains actions - you can add and remove associations.

If an action is a member of multiple AccessGroups, the result will be:

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

And to make the result visible:

(Group1.IsVisible OR Group2.IsVisible OR Group3.IsVisible) AND action.OptInInContext
This page was edited 43 days ago on 04/03/2024. What links here