| 43 | 58 | * Users will be stored in the !MolgenisUser table. Furthermore, there will be one Administrator and one Public User. |
| 44 | 59 | * 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. |
| 45 | 60 | * Column rights: these we can achieve through an extra, optional field in the Table rights table. This field can contain a name of a field (column) in the table in question. If none is supplied, the entry is supposed to hold for all fields in the table. If one is supplied, the entry is supposed to hold only for the specified field. There can be multiple entries in the bridge table for a certain table. In that case, the more detailed entries (about columns) take precedence over the more general ones (about tables as a whole). |
| | 61 | |
| | 62 | Proposed solution (rewritten to see if we understand each other): |
| | 63 | * !MogenisEntity and !MolgenisField and !MolgenisScreen are subclasses of !MolgenisElement. Thus we have an extensible way to define elements we want to set permissions on. |
| | 64 | * !MolgenisRole can have zero or more !MolgenisPermission, with each permission being a tuple [role: xref->MolgenisRole, element:xref->MolgenisModelElement, permission: enum[read,write,execute,ownership]]. [[BR]]Thus we can assign permissions to role |
| | 65 | * !MolgenisUser extends !MolgenisRole with password to enable authentication. [[BR]]Thus we can easily assign permissions to an individual. |
| | 66 | * !MolgenisUser can have multiple !MolgenisRole and !MolgenisRole can have multiple !MolgenisUser. [[BR]]Thus we can easily assign a set of permissions to multiple individuals. |
| | 67 | * !MolgenisGroup extends !MolgenisRole to allow the definition of groups of people (instead of groups of permissions). See row-level security. |
| | 68 | * there will be one Administrator and one Public User. |
| | 69 | * For each individual the total set of permissions is calculated and broader permissions overrule narrow permissions (e.g. entity permission implies permissions on all fields, ownership implies read and write] |
| | 70 | |
| | 71 | Decisions: |
| | 72 | * permission field in MolgenisPermission could be xref instead of enum. Advantage: open ended. Drawback: harder to program. |
| | 73 | * !MolgenisElement could be made generic so you don't need subclasses. Advantage: easier to program. Drawback: loose information that we may want to use in other places. |
| | 74 | |
| | 75 | |
| | 76 | == Dynamic permissions: row level security or 'sharing' == |
| | 77 | |
| | 78 | Expected user interface during editing: |
| | 79 | {{{ |
| | 80 | > Sharing details [hide] |
| | 81 | |
| | 82 | Owner: me |
| | 83 | Can view: Maggie (user) [-][+] |
| | 84 | Can edit: John (user) [-] |
| | 85 | My best friends (group) [-][+] |
| | 86 | }}} |
| | 87 | |
| | 88 | Proposed solution1: big helper table |
| 46 | 89 | * 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. |
| 47 | 90 | * 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! Maybe it turns out that this "big table" approach is not feasible. |
| 48 | 91 | * We will add a plug-in to the Auth module where authenticated users can request rights on tables, columns and/or rows. The requests will be sent to the owners. |
| 49 | 92 | * We will add a plug-in to the Auth module where users can manage the rights on tables, columns and/or rows of which they are owners. Here they can see the current requests and act on them. |
