Changes between Version 17 and Version 18 of Modules/Auth

Timestamp:

2011-01-13T15:25:04+01:00 (14 years ago)

Author:

Erik Roos

Comment:

--

Modules/Auth

@@ -42 +42 @@
 
  * Users will be stored in the !MolgenisUser table. Furthermore, there will be one Administrator and one Public User.
- * Table rights: these will be managed through a bridge table in which each row links to a !MolgenisEntity (through its name) and a !MolgenisUser. There will also be a field 'rights' that details the kind of authorization (an enum consisting of read, write, execute and owner). This way we can achieve many-to-many relationships.
+ * Table rights: these will be managed through a new bridge table in which each row links to a !MolgenisEntity (through its name) and a !MolgenisUser. There will also be a field 'rights' that details the kind of authorization (an enum consisting of read, write, execute and owner). This way we can achieve many-to-many relationships.
  * Column rights: these we can achieve through an extra, optional field in the Table rights table. This field can contain zero or more names of fields (columns) in the table in question. If none are supplied, the entry is supposed to hold for all fields in the table. If one or more are supplied, the entry is supposed to hold only for the specified fields. There can be multiple entries in the bridge table for a certain table. In that case, the more detailed entries take precedence over the more general ones.
+ * Row rights: for this we introduce another optional field in the Table rights table, namely an xref to a row in the table in question. Every row already has an (autogenerated) id field so this is easily done. With this extra field in place we can have very specific entries detailing what rights a certain user has on a combination of a column and a row in a certain table (so we can in fact have "cell rights"). The remark about precedence for the column rights also holds for this.
+ * So we end up with one extra bridge table having entries for combinations of tables, columns, rows, users and kinds of rights. All queries should involve joins with this table to restrict the result set based on what the current user is allowed to see/edit/execute. We have to find out what this will do with the performance of our applications!
 
 [[BR]]