Propositions for the management of the rights

From Armarius

Return to development documentation Development_documentation

Contents 1 Specifications 1.1 Rights for the collections/subcollections 2 Last specifications (30/07/07) 3 Interfaces and tables of the database used (in complement of the tables already described)

[edit] Specifications

[edit] Rights for the collections/subcollections

• There will be rights only for collections and subcollections, and more precisely, on the content of collections and subcollections.

Using "content" means pages. So, these rights are completly independant from the rights of the Armarius system that have already been programmed. (administrate the system : create users, manage users, create groups, manage groups, rights to do all the operations on collections We need to discuss this. We need to change at least the user type names (Elod))

• One user belongs to one or several groups and there are only specific rights for a certain group on a certain collection or subcollection.
• The rights for a collection or a subcollection are :

* R: The group has the right to read only the content of the collection or the subcollection
* A: The group can read, annotate, remove or modify its annotations, and search only for his annotations in the content of
the collection or the subcollection and for all the annotations in the content of the collection or the subcollection he has access to.

• If there are rights on a collection or a subcollection and if this collection/subcollection has children (subcollections) which have no rights on them, the right of the parent collection/subcollection are applied to all the children and the descendants in a recursive way. Else, the rights are added (like explained after).
• The rights will be added : for example, for a user, if he belongs to 2 groups (G1 et G2) which have rights on the same collection or subcollection (G1 has the right "A" on the collection c1 and G2 has the right "R" on the collection c2), the rights of the user are added (the user has the right "A" sur c1, so he can read, annotate, remove or modify its annotations, and search only for his annotations in the c1).

Moreover, if a user belongs to the group G3 which has the rigth "R" on c3 and any rights on c4, which is a subcollection of c3, it will read all the content of c3, except the content of c4.

• Because, of course, if a group hasn't rights on the collection or subcollection, it can't have access on the content of it (so, it can't see that the collection or subcollection exists) !

• Questions : Maybe establish a default group when a new user is registered ? But what will be the rights to give to this group ? On what collections ?

• This is to be defined when creating the collection. The problem I see is the we cannot restrain rights on sub collections in this additive way. For example if c11 is a subcollection of c1 than if the group G1 has A rights on c1 they will have A rights on c11 as well, we cannot say that they hav A rights on c1 but only R rights on c11.

[edit] Last specifications (30/07/07)

• The rights are only put on the real collections and not on the virtual collections.

• We have decided to separate the rights on the collections (read, annotate,read/annotate) from the rights on the users (system administration with creation of users, groups, rights of groups on collections, creation of real collections and their associated views)). So, a new table will be created such as :

armarius_administration containing a field admin_id and a field admin_user_id. This last field is a foreigh key referring to the table armarius_users.

Here is the script of creation of armarius_administration

• There will be a group for the users who are not registered. This group will have rights on collections chosen by the admin.

• When a user is registered in the database, he belongs to a default group which has rights on collections chosen by the admin.

• Precisions : the rights are defined on collections ; so, the subcollections have the same rights that the collection they belong to.

[edit] Interfaces and tables of the database used (in complement of the tables already described)

• Tables

We will use the table armarius_rights created such as : armarius_rights (rg_col_id, rg_group_id, rg_rights) . rg_rights is a binary word (in SQL, we will choose a mediumint) that encodes permissions like in Unix system. It will have 8 figures like this : 00000011 with R corresponding to the first 1 and A corresponding to the second 1.

Here you can see the new structure of the database of Armarius [[1]]

• Interfaces

Two interfaces are needed : one to see the rights established on groups for a selected collection or subcollection.
The other to establish the rights for a selected collection/subcollection.

In them, there will be (like in the management of collections) a Javascript presentation of the content of the collections to facilitate the access and the browsing in the content and the operations to do on it. So, we will use once again a tree with nodes which are collections, subcollections and pages. There's a button near to each node and clicking on it, allows to see the subcollections and pages (if they exist) which there are in it ; clicking on the name of the collection or the subcollection will allow to choose an operation to do on it (see the rights of groups on it or establish rights of groups on it).

• Image of the first proposed interface (to see the rights established on groups for a selected collection or subcollection)

See the interface : [[2]]
In fact, by clicking on the name of a collection/subcollection on the tree and choosing the operation "See the rights", a heading about the rights of groups on the collection/subcollection appears.

• Image of the second proposed interface (to establish the rights for a selected collection/subcollection)

See the interface : [[3]]
In fact, by clicking on the name of a collection/subcollection on the tree and choosing the operation "Give rights", a heading to give rights to groups appears. For each right (R, A and F), we can give this right to one or several groups (which are registered in the database) by clicking on "Add" and remove this right for the group by clicking on "remove". To validate, we have ton click on the button "OK".