Changes between Version 26 and Version 27 of Modules/Auth

Timestamp:

2011-01-17T15:59:57+01:00 (14 years ago)

Author:

rwagner

Comment:

--

Modules/Auth

@@ -102 +102 @@
 Proposed solution 2: superclass
 * There is an interface !RowLevelSecurity that contains fields [owner: mref->!MolgenisUser, shareRead: mref->!MolgenisRole, shareWrite: mref->!MolgenisRole]. [[BR]]Thus a user can choose to share data with the selected groups or individuals. 
+> R1: We don't think it is desireable to change the entities by adding three mref's.
+> R2: Interfaces currently cannot contain mref's. Why?
 * Only the owner can change shareRead and shareWrite properties.
 * For sharing one can only choose !MolgenisRole that the owner is member of, i.e. you can only choose groups you are part of or individuals you can find (i.e. that have given you read permission on their profiles).
+> Q: What is a profile? How important is that?
 
 Discussion:
 * We need a way to define that entities inherit permissions from its 'container'. For example: 'Investigation' could be a container and all !InvestigationElement have by default the same permissions.
+> R: Is very specific and therefore not part of v1.
 * We want to be able to locally override permissions. For example, Data is an InvestigationElement that we may want to limit edit permissions to a subgroup. 
 * This data model depends on the capability to choose what type to search (groups or users); we need to make 'xref' select boxes smarter for this!