Changes between Version 25 and Version 26 of Modules/Auth

Timestamp:

2011-01-17T15:47:05+01:00 (14 years ago)

Author:

rwagner

Comment:

--

Modules/Auth

@@ -62 +62 @@
 Proposed solution (rewritten to see if we understand each other):
 * !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?
 * !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.
 * there will be one Administrator and one Public User.
@@ -71 +73 @@
 Decisions:
 * permission field in MolgenisPermission could be xref instead of enum. Advantage: open ended. Drawback: harder to program.
+> 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.
 
 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 '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'.
 
 === Dynamic permissions: row level security or 'sharing' ===