Changes between Version 29 and Version 30 of Modules/Auth

Timestamp:

2011-01-18T13:41:26+01:00 (14 years ago)

Author:

rwagner

Comment:

--

Modules/Auth

@@ -63 +63 @@
 * !MogenisEntity and !MolgenisField and !MolgenisScreen are subclasses of !MolgenisElement. [[BR]]Thus we have an extensible way to define elements we want to set permissions on.
 > Q: Do we really need to distinguish between !MogenisEntity and !MolgenisField and !MolgenisScreen? Why not simply add further fields to MolgenisEntity?
+>> A: Yes, use !MogenisEntity and !MolgenisField and !MolgenisScreen because we have them anyway as part of Molgenis.
 * !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
 * !MolgenisUser extends !MolgenisRole with password to enable authentication. [[BR]]Thus we can easily assign permissions to an individual.
 * !MolgenisUser can have multiple !MolgenisRole and !MolgenisRole can have multiple !MolgenisUser. [[BR]]Thus we can easily assign a set of permissions to multiple individuals.
 > Q: Why could !MolgenisUser's have multiple !MolgenisRole's, i.e. why is the relation between !MolgenisUser and !MolgenisGroup not enough?
-* !MolgenisGroup extends !MolgenisRole to allow the definition of groups of people (instead of groups of permissions). See row-level security.
+>> A: For the beginning rename MolgenisRole to MolgenisGroup. Extend MolgenisUser from MolgenisGroup. Make mref from MolgenisUser to MolgenisGroup.
 * there will be one Administrator and one Public User.
-* 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]
+* For each individual the total set of permissions is calculated and narrower permissions overrule broader permissions (e.g. entity permission implies permissions on all fields, ownership implies read and write]
 
 Decisions:
@@ -75 +76 @@
 > R: Enum will be used, because set of permissions is static.
 * !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.
-> R: See above.
+> R: Not generic.
 
 Discussion:
 > Q: What if I have readpermissions on 'A' and A has an xref to B. Do I than automatically get readpermission on 'B'?
 >> A: We could make a special exception for the 'xref_label' of the entity. That should ALWAYS be readable. But without read permissions, users cannot choose other fields of 'B'.
->>> A: We don't agree on that. Only the id of 'B' should be visible. If more is necessary, permissions have to be set for 'B'.
+>>> A: None of the fields of 'B' will be visible. If they should, permissions have to be set.
 
 === Dynamic permissions: row level security or 'sharing' ===