wiki:Develop/Users-Authorities
Last modified 6 years ago

Users

Usermanagement is done via the Usermanager class. The following database tables are relevant:

  • corinisusers: username, password, onlinestatus, lastlogin, activestatus,...
  • corinisusersonline: sessionid, userid,.. of all online users
  • corinisprofilerfield: definition of all profilefields
  • corinisprofiler: user - profilerfield - value relation

Groups

Groupmanagemant is done via the Usermanager class (Group = MainEntry?)

Groups are a collection of authorities. Users can be assigned to several groups. Also groups can be assigned to groups therefor creating a group-hierarchie with parent and child groups (inheriting authorities from the parent groups). Note that each group can only have 1 parent so in the end you will have a "group-tree".

The following database tables are relevant:

  • corinisauthoritygroup: group definition = name, description\r\n
  • corinisauthorityusergroup: the assignment table: consists all user-group, group-group relations

Authorities

Authoritymanagement is done via the class AuthorityManager?.

Authorities in Corinis are divided into

  • Functionauthorities: The Authority to perform a function - i.g. create a document
  • Elementauthoritiy: authorities for specific elements - i.g. delete a specific document

Each type of authority is saved in a different table:

  • corinisfunctionauthority: id, userid, groupid, authority, source
  • coriniselementauthority: id, userid, groupid, element, source, rightview...specialright5

Users or groups All authority tables and methods if not specificly made for either users or groups always takes a userid and a groupid parameter. This means you can choose either a userid OR a groupid. The other has to be -1. So for instance if userid = 123123123 and groupid = -1 this means that this authority/function etc. is meant for the user (the other way round would be for example userid=-1 and groupid = 3324).

Function Authorities Each function authority is a so called "authority string" - i.g. FORUM_VIEW. If one want to perform a function it will be checked if he has the right to do that. All available authorities are defined in the corinisauthoritybase table and are managed via the AuthorityBaseManager? class. When setting up Corinis this table will be filled with all available authorities (which are defined in the module-classes - e.g. each module defines via the "getModuleAuthorities" method, which authorities it checks). This authorities obviously can't be deleted or modified by the user - but it is/will be possible to define own authority strings (i.g. for interfaces to external systems etc.) which then can be assigned to users/groups.

Element Authorities An element authority is defined through a userid/groupid, elementid (the id of the element), module (the module i.g. Forum, CMS, etc.), source (derived or not) and the following authorities (each one is a field in the elementauthority table):

  • rightview
  • rightcreate
  • rightmodify
  • rightdelete
  • rightqm
  • specialright1
  • specialright2
  • specialright3
  • specialright4
  • specialright5

The specialrights are additional rights for special needs in a module (if needed). So if there are any special operations in a module which can't be covered by the above 5 - one may use up to 5 additional rights.

Inheritance

If you assign a group to anothergroup (child-parent) or a user to a group the group or user inherits all rights from the parentgroup. For example:

Group A - Group B - Group C

User 1 is assigned to group B, user 2 is assigned to group C

Then: Group B inherits all rights from group A (therefor user 1 has all rights which are directly assigned to him and all rights of Group A and Group B), Group C inherits all rights from group A and Group B (therefor user 2 has all rights which are assigned to him directly and all rights of group a, b and c).

How it works

User All authorities which are assigned directly to a user are saved in the function/elementauthority tables with userid=the id of the user, groupid=-1 and source = the id of the user. When checking for authorities, this directly assigned rights will be checked. Furthermore all groups the user is assigned to will be loaded (from the table authorityusergroup) and cached. In a second step (if necessary) it will be checked if any of the groups the user is assigned to has the authority. The result (true/false) will be returned.

Groups For authorities which are assigned directly to a group it works similar to users - e.g. groupid = id of the group, userid=-1, source= the id of the group. If the group inherits from a parent group (= is assigned to a parent group) the group inherits all rights of this group. All authorities of the parent group will then be copied to the child group. Because the source field never changes value it indicates where the authority comes from - i.g. in the example above all authorities which group C inherits from group a (over group b) will have source = id of group a. So for all authorities assigned directly source = groupid, for all inherited rights source = groupid from which the authority comes from. Therefore if you list all authorities whith a certain groupid - you get all authorities this group has (directly assigend and inherited).