TOC?

This page aims to describe the two rights systems in BW: the system from the old BW code and the new implemented in the Rox code.

Old system (current system)

This is based on two tables: rights and rightsvolunteers. Part of the design is based on the concept that only volunteers can have rights - whatever normal members can do does not have anything to do with rights.

Rights are designed as abstract areas of action, like accepting, logs, forum moderation, etc.

Table layouts

• rights
  • id
  • created
  • Name
  • Description
• rightsvolunteers
  • id
  • IdMember - id of the member who have the right (foreign key)
  • IdRight - links to rights table
  • Level - is an integer, it should reflect if the right is active or not, in the past it was used for different level or rights (which is a deprecated method )
  • Scope - has meaning dependent upon rights, it is a typical subright, It is plain text set of values between double quotes
  • Comment : describe the usage of the right for volunteers who manage it
  • updated
  • created

For a given member to have a right the means to have a row inserted in rightsvolunteers describing a certain level and scope for a certain right.

Considerations

• It has been very easy to set up in motion
• There's no check on duplicated rows (the interface always checks that no duplication occurs but there are no restraints in the database)
• There's duplicated data in it. To have a right is meaningless unless you have the right - a right that is turned off is not a right. In other words, level duplicates the fact that the row exists in the first place
• The data model uses multivalue fields, making lookups in other tables impossible. Translation rights, for instance, can not be checked against the languages table without going through PHP code
• The data model does not allow for having the same right with different scopes on different levels. This is possibly not a problem, as long as levels are not used but implemented as different rights
• It doesn't allow for grouping rights (like a set of permission for a certain role)

Rox system (current system)

This is based on five tables:

• members_roles
• roles
• roles_privileges
• privileges
• privilegescopes

There is no restriction on which kind of member can have rights in this system - having a role does not in itself make you an admin or anything like it.

There are three design considerations behind this model:

1. Assigning roles allows for better granularity and handling of rights than just assigning permissions/privileges.
2. It has to be possible to have a role for a given object like a group or a trip, instead of for all groups or trips. This is the reasoning behind the privilegescopes table.
3. Privileges are related to controllers in the code. I.e. privileges are related to the actions you can carry out in the code. Hence, a role can be seen as the different - restricted - actions you can carry out because you have that role.

Table Layouts

• members_roles
  • IdMember
  • IdRole
  • updated
• roles
  • id
  • name
  • description
• roles_privileges
  • IdRole
  • IdPrivilege
  • updated
• privileges
  • id
  • controller
  • method
  • type - the type of object that this privilege gives access to. Typically entities but can be anything, including abstract concepts. In other words, the restraint on this is in the code (jy: please explain more, the other types for example)
• privilegescopes
  • IdMember
  • IdRole
  • IdPrivilege
  • IdType - id of the object the privilege is restricted to. Can be * to signify no restriction
  • updated

Considerations

• There is some duplication of data in the privilegescopes table
• It can only be used inside a Rox model application or similar (A Controller is needed). Strictly speaking not a problem as we're migrating towards Rox code and all non-Rox code should be discarded. If there's a need for using it in the Rox framework (i.e. outside Rox MVCs) it's easy to instantiate an EntityFactory? and get access to the rights system through that - so it can technically be used anywhere.

Code

Assigning a role to a member is done by creating the role-entity and then either calling addForMember($member, $scopes) on it or passing it along with a member entity to a MemberRole entity (specifically the createMemberRoleLink($member, $role) method)

Improvements

• Make role descriptions translatable
• Create exclusive roles - these work on excluding privileges within a class
• Remove the reference to privileges from the privilegescopes table - a role should be for an object, it shouldn't be subdivided
• Create interface for handling rights
• May be a comment field in privileges Scope is needed (to explain the purpose of the Scope). This should hopefully be self-explanatory: scopes are either global (in which case we're dealing with a BW vol) or local (in which case we're dealing with members). Either way, we're dealing with access that is self-explanatory: the member has access because he has a specific relation to the object at hand and the volunteer has access globally because he/she has been made a volunteer with access. I think that what you're really looking for is not comments but logging of actions: i.e. giving someone privileges to do some things should be logged. However, a comment field is not the best way for this, the log is.