Project

General

Profile

WorkshopRightsAndRoles2017-11 » History » Version 35

Andreas Kohlbecker, 11/30/2017 11:02 AM

1 1 Andreas Kohlbecker
# Workshop Rights & Roles 2017-11
2
3 6 Andreas Kohlbecker
see also #7089
4
5 5 Andreas Kohlbecker
Results of the Rights & Roles workshop held on November 27th - 30th at the BGBM.
6
7
Attendees: Andreas Kohlbecker, Katja Luther, Andreas Müller, Patrick Plitzner  
8
9
------
10
11 21 Andreas Kohlbecker
# Continued create problem and private entity graphs
12 1 Andreas Kohlbecker
13 10 Andreas Kohlbecker
The "*continued create*" problem exists in cases when a user only is granted to perform `CREATE` operations for a specific entity type but misses having the `UPDATE` grant. Users may need to continue to edit the newly created entity and other new parts in the connected entity graph.
14 1 Andreas Kohlbecker
15 16 Andreas Kohlbecker
In consideration of this problem we introduced the concept of directed "***private entity graphs***". *Private entity graphs* are *owned* by the creator of all entities involved. An entity is owned by the creating user as long the `createdBy`  and `updatedBy` are equal. 
16 10 Andreas Kohlbecker
  
17 1 Andreas Kohlbecker
{{thumbnail(private-entity-graphs.JPG, size=500)}}
18 10 Andreas Kohlbecker
19 31 Andreas Müller
As long as as *private entity graph* is completely disconnected from the rest of the world the case is quite simple. But it is getting more difficult once 
20 10 Andreas Kohlbecker
21
A. the graph is becoming associated to other entities which are not owned by the creator of the *private entity graph*. 
22 29 Andreas Müller
B. an entity inside this graph is being updated by another user. This changes the `updatedBy` property and this entity is no longer owned by the creator. Updated by can't be changed back to the creator as the creator does not have update rights on something he/she currently does not own.
23 10 Andreas Kohlbecker
24 31 Andreas Müller
In both cases this "***ownership***" change needs to propagate through the graph to other entities. This propagation travels along the directed edges of the graph. This directional property of the edges is expressed in the diagrams above by red arrow heads whereas the arrow head can be dashed. A dashed arrow head means that it is optional depending on the specific project requirements. An entity `A` which is connected by a directed edge with an entity `B` (`A<----B`) provides data for `B` from which `B` essentially depends. `A` cannot be changed without implicitly changing `B`. That `B` potentially ***blocks*** modifications of `A`. This blocking actually manifests when the "***owning***" user of `A` loses the exclusive ownership of `B` in turn of the two cases described above.
25 10 Andreas Kohlbecker
26 32 Andreas Müller
The blocking nature of an edge, that is of an entity class property, can be expressed in the model classes by introducing according annotations. See strategy 5).
27 8 Katja Luther
28 1 Andreas Kohlbecker
## Strategy 1 - "Publish View"
29 13 Andreas Kohlbecker
30 28 Andreas Kohlbecker
A "view" has associations to all entities which are included into the view.
31 1 Andreas Kohlbecker
32
Views potentially can replace general UPDATE & READ permissions. In this case `Users` are participants of specific views by being associated with it. 
33 28 Andreas Kohlbecker
34 33 Andreas Kohlbecker
The views strategy opens a mechanism to handle those events when a *private entity graph* is becoming connected to a non private entity which causes the graph or parts of being blocked:
35 1 Andreas Kohlbecker
36 33 Andreas Kohlbecker
{{thumbnail(strategy_1.jpg, size=500)}}
37 1 Andreas Kohlbecker
38 33 Andreas Kohlbecker
1. The *private entity graph* get associated with a non private entitiy
39
2. The  formerly entity `TypeD` is now blocked and can in principle no longer be edited by the user having only the `CREATE` authority.
40
3. depending on the project preferences the entity `TypeD` is 
41 34 Andreas Kohlbecker
    * made public automatically by asscoiating it with the 'PublishView' 
42
    * is put into the 'PublishView' manually in an editorial, curatorial process
43 32 Andreas Müller
44 35 Andreas Kohlbecker
As noted in point 2) editing of `TypeD` is only blocks in principal but can be allowed as long it is not incorporated into the 'PublishView'. So this strategy **can replace (in some/all cases?) the strategy 2b)** which also allows to continue to edit blocked *private entity graphs*.
45 28 Andreas Kohlbecker
46 33 Andreas Kohlbecker
Different views can exist for published data and data in review (maybe there are more views if the project needs more states). Data which are "under constructions" can be updated by the original owner and are not visible to the public. 
47
48 13 Andreas Kohlbecker
49 14 Andreas Kohlbecker
## Strategy 2 - "Per property permissions"
50 1 Andreas Kohlbecker
51
{{thumbnail(strategy_2.jpg, size=500)}}
52 16 Andreas Kohlbecker
53 17 Andreas Kohlbecker
Grant authorities per entity class property. 
54 1 Andreas Kohlbecker
55 17 Andreas Kohlbecker
**2a)**
56
For non cdm-entity properties this allows users to edit this and only this specific field.
57 2 Andreas Kohlbecker
58 17 Andreas Kohlbecker
**2b)**
59 9 Katja Luther
60 32 Andreas Müller
For cdm-entity properties, this allows to express that a user can continue to edit an *owned* entity or *private entity graph* despite the fact that it is associated to a *non-private* entity which is connected via a "*blocking*" relation.  Without this explicit per property permission the formerly private entity and subsequently parts of the private entity graph would be blocked by creating this relation. 
61 13 Andreas Kohlbecker
62 17 Andreas Kohlbecker
63 13 Andreas Kohlbecker
## Strategy 3 - "Unpublished Entities - general READ rights"
64 1 Andreas Kohlbecker
65 32 Andreas Müller
**This strategy must be implemented in any case,** since general READ permissions are a requirement in multiple projects. Euro+Med is an example.
66 22 Andreas Kohlbecker
67 3 Andreas Kohlbecker
{{thumbnail(strategy_3.jpg, size=500)}}
68 13 Andreas Kohlbecker
69 17 Andreas Kohlbecker
In publication tools we need different possibilities to filter:
70 32 Andreas Müller
Filtered DTOs to provide DTOs containing only information the user has the permissions to see.
71
For the case of collections of CDM entities the user has the permission to see them and CDM entities the user has no permission to see, we need filtered collections for the service layer.
72 9 Katja Luther
73 32 Andreas Müller
The editor does not need filter but it should be possible to hide information (undisclosed entities)
74 1 Andreas Kohlbecker
75 14 Andreas Kohlbecker
## Strategy 4
76
77 32 Andreas Müller
Managing referencing objects information in the referenced CDM entity. 
78 14 Andreas Kohlbecker
79 1 Andreas Kohlbecker
{{thumbnail(strategy_4.jpg, size=500)}}
80 14 Andreas Kohlbecker
81 32 Andreas Müller
Implementing this strategy involves a model change. CDM classes will be extended by adding the below fields for each collections of CDM entities. Theses can either got directly into the entity class or may be implemented by introducing a separate Class to hold this information. The benefit of the latter option is that updating the referencing objects information is not causing an update of the referenced entity record. In the first case it is needed to suppress auditing and changes of the `updatedBy` and `updatedWhen` fields of the referenced entity.
82 14 Andreas Kohlbecker
83 15 Andreas Kohlbecker
Explicitly managing and persisting the referencing objects information avoids excessive database querying in order to find the referencing objects via the `ICdmGenericDao.getReferencingObjects(CdmBase referencedCdmBase)` method. To determine the bounds of  *private entity graphs* it is not needed to get old of the referecing objects, it merely is sufficient to know if there are more than one different users *owning* the referencing objects.   
84
85 1 Andreas Kohlbecker
* `User {collection_property_name}FirstReferencingObjectsUser`: A reference to the the user which was the in the 'updatedBy' field of the first entity ever referencing this object.  
86 15 Andreas Kohlbecker
* `boolean {collection_property_name}IsMultiplyReferenced`: true if there are more then one referencing objects (optionally as count value?)
87
* `boolean {collection_property_name}IsReferencedByMultiplyOwnedEntities`: true if the referencing objects are "*owned*" by multiple users. (optionally as count value?) 
88 1 Andreas Kohlbecker
89
The semantics of "*owned*" in the context of this strategy refers to the user referenced in the `updatedBy` field. In case `updatedBy` is null it refers to `createdBy`. **This semantics  of *ownership* is different to that in the *private entity graphs*!**
90
91 19 Andreas Kohlbecker
**TODO**: Why is `{collection_property_name}FirstReferencingObjectsUser` needed and how can this information be updated once the according referencing entity is updated by a different user?  
92 15 Andreas Kohlbecker
93 19 Andreas Kohlbecker
## Strategy 5
94 1 Andreas Kohlbecker
95
{{thumbnail(strategy_5.jpg, size=500)}}
96 3 Andreas Kohlbecker
97 23 Andreas Kohlbecker
Introduction of two new method level java annotations by which the *blocking* nature of a property can be expresses (see above for more details on *blocking*):
98
99
* **@isBlockedBy**: Annotation for the arrow end, head, of the directed edge.
100
* **@isBlocking** : Annotation for the tail of the the directed edge.
101
102
These  annotations are being interpreted by business logic classes which implement the propagation of *blocking* events in the *private entity graphs*. This propagation can lead to an decision to 
103
104
* A. implicit deny editing of the entities in the subgraph
105
* B. withdraw previously granted per entity permissions (see strategy 6)
106
107 19 Andreas Kohlbecker
## Strategy 6
108
109 3 Andreas Kohlbecker
{{thumbnail(strategy_6.jpg, size=500)}}
110 23 Andreas Kohlbecker
111 24 Andreas Kohlbecker
Explicitly grant and withdraw per entity granted authorities as currently implemented for the phycobank registry (see #6867 & #4305) 
112 1 Andreas Kohlbecker
113
{{thumbnail(per_entity_permissions_and_groups.jpg, size=500)}}
114 24 Andreas Kohlbecker
115
The per entity granted authorities are either directly associated with the user or could be assigned to per user permission groups. The idea of per  user permission groups is lend from unix where a group is being created per default for each user.  
116 3 Andreas Kohlbecker
117 19 Andreas Kohlbecker
## Strategy 7
118
119 1 Andreas Kohlbecker
{{thumbnail(strategy_7.jpg, size=500)}}
120
121 25 Andreas Kohlbecker
This is the concept of having an explicit workflow state information for an entity type as it is implemented for the `Registration` class. We might want to implement workflow states for each cdm type. By this is would for example become possible to create a new `Term`, use it immediately even if not yet published. The term will undergo a review process during which the decision  is being made whether to publish it or not.
122
123
* This strategy implies strategy 5
124
* This strategy can be replaces by strategy 1
125
    
126
127
(BTW: The flowers are artwork painted by Andreas Müllers' daughters) 
128
129 19 Andreas Kohlbecker
130 20 Andreas Kohlbecker
## Use Cases 
131 19 Andreas Kohlbecker
132 1 Andreas Kohlbecker
{{thumbnail(Usecases.JPG, size=500)}}
133 19 Andreas Kohlbecker
134
135
Table of use cases in which users which only `CREATE` authorities need to perform continued editing. That is these are use cases in which the *private entity graphs* are relevant which can be connected to non-private entities.  The acronym *DS* used in here refers to the term *Data Slave* which has been used as jocular term for users which only `CREATE` authorities for specific entity types. 
136
137
Tables columns: 
138
139
* *no review*: The newly created entities are becoming immediately public
140 1 Andreas Kohlbecker
* *in review/reviewed*: The newly created entities are first being reviewed before becoming public. Maybe the publication is rejected by the reviewer.  
141 20 Andreas Kohlbecker
142
In both columns the strategies required to realize the use case are noted. Often strategies need to combined, this is expressed by `+`, optionally strategies are in brackets `()`. `||` mean OR and expresses alternative combinations of strategies. 
143 19 Andreas Kohlbecker
144
Use cases 
145
146
* *DS-non-entity*: editing of a single non cdm entity property like a persistent ID, geo reference, etc. This is a special case since it not involves the creating of a *private entity graph*.
147 26 Andreas Kohlbecker
* **TODO** ... to be continued
148 1 Andreas Kohlbecker
149 21 Andreas Kohlbecker
# Combing GrantedAuthorities
150
 
151 1 Andreas Kohlbecker
{{thumbnail(GrantedAuthorities_1.jpg, size=500)}}
152 26 Andreas Kohlbecker
153
* The class `CdmAuthority` needs to become a cdm model class which replaces, extends `GrantedAutorityImpl`.
154 3 Andreas Kohlbecker
155 18 Andreas Kohlbecker
{{thumbnail(GrantedAuthorities_2.jpg, size=500)}}