Jump to: navigation, search

Difference between revisions of "User Groups and Rights"


m (See Also)
 
(One intermediate revision by the same user not shown)
Line 34: Line 34:
 
* [[USERGROUP|User Groups]]
 
* [[USERGROUP|User Groups]]
 
* [[LOGIN|Logins]]
 
* [[LOGIN|Logins]]
 +
* [[Configuration_Files/AppSettings.config|UBIK Content web service configuration]]
 +
* [[HowTo:Use_Change_Detection_via_Change_Notifications]]
  
 
[[Category:Coding|User Groups and Rights]]
 
[[Category:Coding|User Groups and Rights]]

Latest revision as of 11:52, 7 May 2025

Rights can be assigned to users via User Groups.

Big Picture

Big Picture: User, Groups and Rights

When a user requests an object from the web service (via the mobile app), the correct rights are evaluated. The rights for an object are defined by programmatic customizing, overriding a respective method "CustomGroupRights". A user can be (reverse) related to multiple user groups, which can also inherit from other user groups . More specific group rights override rights assignments to more general groups. The possibility to assign a user to different groups (not necessarily inheriting from each other) can lead to multiple (at first glance, conflicting) rights for different groups the user is in. However, the rights have a priority assigned to them, and the highest right is chosen in the end.

Rights Customization

See Configure Users and User Rights.

Rights Evaluation

As described in the Big Picture, there is a hierarchy to user groups, which is now also considered by the UBIK Content web service . The evaluation process goes as follows:

  1. Get object's custom group rights
  2. If they are not defined, default to "Write"
  3. Get user's group hierarchy
  4. Find the most specific group rights for this individual case
  5. Find the highest available right (first is highest):
    1. RestrictiveNoRight
    2. RestrictiveRead
    3. Write
    4. Read
    5. NoRight

... where "RestrictiveNoRight" will be translated into "NoRight" and "RestrictiveRead" will be translated into "Read" ultimately - they are just used to have a way for active restriction instead of only extension (similar to the idea of blacklisting instead of whitelisting).

Caching

There was a complete overhaul of the user group caching mechanism of the UBIK Content web service . It automatically establishes and maintains a working memory structure of the assignments between users and groups as well as the group hierarchy for fast access. If change detection is enabled for the webservice (via AppSettings.config: setting UBIK.Service.EnableChangeNotifications = 1), the cache is updated as fast as possible as soon as any relevant change is detected. Otherwise, the cache is updated wrt. a login when this hasn't happened for some time and group data is being fetched. One of the changes from the overhaul is that updates are not just scheduled asynchronously, but every cache access must await pending updates if they are relevant, while still aiming for a very fast evaluation - carefully weighing performance against integrity.

See also