WorkshopRightsAndRoles2017-11 » History » Version 16
Andreas Kohlbecker, 11/29/2017 04:07 PM
1 | 1 | Andreas Kohlbecker | # Workshop Rights & Roles 2017-11 |
---|---|---|---|
2 | |||
3 | 6 | Andreas Kohlbecker | |
4 | see also #7089 |
||
5 | |||
6 | 5 | Andreas Kohlbecker | Results of the Rights & Roles workshop held on November 27th - 30th at the BGBM. |
7 | |||
8 | Attendees: Andreas Kohlbecker, Katja Luther, Andreas Müller, Patrick Plitzner |
||
9 | |||
10 | |||
11 | ------ |
||
12 | |||
13 | 10 | Andreas Kohlbecker | ## Continued create problem and private entity graphs |
14 | 1 | Andreas Kohlbecker | |
15 | 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. |
16 | 1 | Andreas Kohlbecker | |
17 | 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. |
18 | 10 | Andreas Kohlbecker | |
19 | 1 | Andreas Kohlbecker | {{thumbnail(private-entity-graphs.JPG, size=500)}} |
20 | 10 | Andreas Kohlbecker | |
21 | As long a *private entity graph* is completely disconnected from the rest of the world the case is quite simple. But it is getting fare more interesting once |
||
22 | |||
23 | A. the graph is becoming associated to other entities which are not owned by the creator of the *private entity graph*. |
||
24 | 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. |
||
25 | |||
26 | 16 | Andreas Kohlbecker | In both cases the 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. A 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 in turn of the tow cases described above. |
27 | 10 | Andreas Kohlbecker | |
28 | The blocking nature of an edge, that is of a entity class property, can be expressed in the model classes by introducing according annotations. See strategy 5). |
||
29 | 2 | Andreas Kohlbecker | |
30 | 8 | Katja Luther | |
31 | 1 | Andreas Kohlbecker | ## Strategy 1 - "Publish View" |
32 | 13 | Andreas Kohlbecker | |
33 | 8 | Katja Luther | {{thumbnail(strategy_1.jpg, size=500)}} |
34 | 13 | Andreas Kohlbecker | |
35 | 4 | Katja Luther | This strategy works with different views 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 orginal owner and are not visible to the public. |
36 | 7 | Katja Luther | When the created/updated data are reviewed they are added to the "publish view". With this action the update rights can be removed from the creator, if they should not be editable by "normal" users. |
37 | 4 | Katja Luther | |
38 | 11 | Katja Luther | Depending on the role of the creator or the workflow of the project the new created object can be added to the publish view immediately or managed. |
39 | 13 | Andreas Kohlbecker | |
40 | |||
41 | 14 | Andreas Kohlbecker | ## Strategy 2 - "Per property permissions" |
42 | 1 | Andreas Kohlbecker | |
43 | {{thumbnail(strategy_2.jpg, size=500)}} |
||
44 | 16 | Andreas Kohlbecker | |
45 | Grant authorities per entity class property. 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 an *non-private* entity which is connected via a "*blocking*" relation. |
||
46 | 2 | Andreas Kohlbecker | |
47 | 9 | Katja Luther | |
48 | 13 | Andreas Kohlbecker | |
49 | |||
50 | 9 | Katja Luther | ## Strategy 3 - "Unpublished Entities - general READ rights" |
51 | 13 | Andreas Kohlbecker | |
52 | 3 | Andreas Kohlbecker | {{thumbnail(strategy_3.jpg, size=500)}} |
53 | 13 | Andreas Kohlbecker | |
54 | 9 | Katja Luther | In publication tools we need different possiblities to filter: |
55 | 12 | Katja Luther | Filtered DTOs to provide DTOs containing only informations the user has the permissions to see. |
56 | 9 | Katja Luther | 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. |
57 | |||
58 | The editor does not need filter but it should be possible to hide informations (undisclosed entities) |
||
59 | 1 | Andreas Kohlbecker | |
60 | 14 | Andreas Kohlbecker | ## Strategy 4 |
61 | |||
62 | Managing referencing objects information in the referenced cdm entity. |
||
63 | |||
64 | 1 | Andreas Kohlbecker | {{thumbnail(strategy_4.jpg, size=500)}} |
65 | 14 | Andreas Kohlbecker | |
66 | 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. |
||
67 | |||
68 | 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. |
69 | |||
70 | 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. |
71 | 15 | Andreas Kohlbecker | * `boolean {collection_property_name}IsMultiplyReferenced`: true if there are more then one referencing objects (optionally as count value?) |
72 | * `boolean {collection_property_name}IsReferencedByMultiplyOwnedEntities`: true if the referencing objects are "*owned*" by multiple users. (optionally as count value?) |
||
73 | 1 | Andreas Kohlbecker | |
74 | 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*!** |
||
75 | 15 | Andreas Kohlbecker | |
76 | **TODO**: Why is `{collection_property_name}FirstReferencingObjectsUser` needed and how must this information be updated once the according referencing entity is updated by a different user? |
||
77 | |||
78 | 3 | Andreas Kohlbecker | |
79 | 2 | Andreas Kohlbecker | {{thumbnail(strategy_5.jpg, size=500)}} |
80 | 3 | Andreas Kohlbecker | |
81 | 2 | Andreas Kohlbecker | {{thumbnail(strategy_6.jpg, size=500)}} |
82 | 3 | Andreas Kohlbecker | |
83 | 2 | Andreas Kohlbecker | {{thumbnail(per_entity_permissions_and_groups.jpg, size=500)}} |
84 | 3 | Andreas Kohlbecker | |
85 | 2 | Andreas Kohlbecker | {{thumbnail(strategy_7.jpg, size=500)}} |
86 | 3 | Andreas Kohlbecker | |
87 | 2 | Andreas Kohlbecker | {{thumbnail(Usecases.JPG, size=500)}} |
88 | 3 | Andreas Kohlbecker | |
89 | 2 | Andreas Kohlbecker | ![](GrantedAuthorities_1.jpg, size=500)}} |
90 | 3 | Andreas Kohlbecker | |
91 | 1 | Andreas Kohlbecker | ![](GrantedAuthorities_2.jpg, size=500)}} |