Project

General

Profile

Actions

feature request #4305

open

newly created entities must stay editable even if a user only has the permission to create them

Added by Andreas Kohlbecker over 9 years ago. Updated about 5 years ago.

Status:
In Progress
Priority:
Priority10
Category:
cdmlib
Start date:
Due date:
% Done:

40%

Estimated time:
Severity:
normal

Description

Users which only have the authority to create an entity CREATE are blocked from changing it afterwards since they miss the UPDATE authority. In this situation it is no possible to change typos or to do other minor fine tuning after the new entity has been saved for the first time.

To circumvent this situation of being locked out in the middle of the actual creation process we discussed the below described solutions. A full solution needs to solve the following two detail problems, which should be considered separately:

  1. Extended create problem
  2. Multiple referencing objects problem.

Concepts

A) continuedCreationTimespan

Once a 'Editor' has created a new entity it is considered being still in the process of being created for some time even if the entity has already been saved to the database. This means that the Authority CREATE implies UPDATE as long as

@now - entity.created < continuedCreationTimespan@}

AK: This approach is not appropriate in the context of applications like phycobank where entity must stay editable as long as the registration process is not completed, this can take several weeks.

B1) no further referencing object of other users

The entity stays editable as long as there are only referencing objects for which the user equals to createdBy and updatedBy in case this is set.

This solution requires to check the whole tree of referencing objects until the process reaches at least one object for which is not editable by the user. This solution might be too extensive in terms of computation, therefor it might be necessary to stop examining the tree after a certain timespan has been exceeded. On the other hand, cases in which this process is potentially running for a quite long time are most probably rather rare, because:

The process stops as soon a non editable referencing entity is reached. And in cases where the tree is big, there will be a lot of referencing object and the probability to find a non editable entity is rather high.

As stated in B2) it would be important to initially deny editing or saving the entity if there are more than one referencing object and to present the user a dialog with a list of all affected referencing objects, so that the user gets a profound and comprehensive knowledge on the consequences of the action.

B2) no further referencing objects

The entity stays editable as long as there is only one referencing object for which the user equals to createdBy and updatedBy in case this is set.
For how to deal with situation in which editing is denied due to multiple referencing object, please see below.

This is a pragmatic approach which covers most use-cases where a user creates e.g. a person which is referenced by exactly one reference.
Generally there are 2 reasons for not giving UPDATE rights to a user:

  1. The user may change a record that is also used by data of another user and the danger is that (s)he changes it in an unwanted way.
  2. The user may change a record that is referenced multiple times and (s)he may not understand well enough that she changes the record for ALL references. May (s)he completely change the name of a taxon name author not realizing that this is correct for one given name but not for 5 other names that also use this name. This is the most dangerous case as data may become completely corrupted. Also checking if the user is the only user who references the record is not a solution here as the user may corrupt his/her own data as well as other's data. In reality it seems to be much more important if an object is only referenced once or multiple times. If referenced once the chance is small that data get corrupted while referenced multiple times the chance is high.

In current TaxEditor we already give exactly this warning (in red) at some places which helps a lot. We could replace the warning by a message that someone has no rights to edit such data.
This could also cover the A) case because in most cases relatively new records are not referenced multiple times.

dealing with 'edit denied' situations due to multiple referencing object

If the object is not editable in this sense the system may create a clone of the object. The clone no longer has no referencing objects and editing it would not have any side effects.

A the original of the cloned object could be marked with a Marker object denoting that a new version of this entity exists as clone. Users entering editors for objects referencing this original entity are informed about the new version, so that (sh)he can decide to use the new entity also in this case.

Using cloned objects, imposes a bit more complexity on the UI development. Let's take a look at the following example for illustrating this:

A user is editing Reference which has a Person as author, (s)he clicks on "Edit author". The Person is references by multiple objects, so the system creates a clone either during the save operation. After the Person editor is closed the Name still has the unmodified Person as author and must be notified about the fact that the edit operation has created a clone of the object. In turn of this notification the name editor switches the author relation do the new name. In case the user is clicking cancel on the name editor the change is not saved and the name still has the old author. Therefore a dialog should warn the user when leaving the editor if the data is unsaved.

C)

rejected due to X.3)

The entity stays editable as long as the user equals to createdBy and updatedBy in case it is set.

When performing the save operation, that is just when the user has clicked "save" and before the actual save transaction has been started, the user is presented a dialog when there are more than one referencing objects. This dialog lists all referencing objects and the user can select those for which the entity being saved should also be changed. For each object it will be checked if the user has the permission to update it (includes extended create). The user an select all objects for which (s)he has the permission. If the user selects all referencing objects the entity is just saved, otherwise a clone is being created which will be used for all selected objects.

This requires the following problems to be solved in case a clone is created:

  • The property which holds the referenced object needs to be known or needs to be found.
  • All objects need to be updated with the cloned object
    • what if the referenced object again has multiple referencing objects? Another referencing objects dialog needs to be opened and so one. How deep will this go into the object graph?

D) per instance UPDATE & DELETE permission.

After creating a new instance the user gets the permission to UPDATE & DELETE exactly this instance.
By this no further interpretation of the CREATE permission as extended create is necessary and the given permission can be revoked again.
The system will care for automatic assignment of the UPDATE & DELETE authority to the user whereas the new authorities will be direly associated
with the user. This has the advantage that the automatically given authorities can not be changed by a user manager via the editor, where only the authorities assigned to groups can be edited.

General considerations

X.1) limiting the amount of clones being created

refers to B2), C)

A clone only needs to be created if the entity is changed significantly. For example changing a persons lifespan usually is not affecting the referencing objects and crating a clone is not needed. A match method could be used to perform this check:

boolean createClone = originalEntityVersion.matches(editedEntityVersion);

X.2) defining related object graph bounds

refers to B1)

When inspection of the graph of referencing objects is needed it is neccesary to define the bounds of the graph to be walked. For example a References is modified a possible branch of referencing objects graph is Reference --> nomenclaturalReference.Name --> name.Taxon --> taxon.TaxonNode --> children.TaxonNode ..... At the point where the walk along the graph reaches the classification tree, that is a TaxonNode it should stop.

Ways to define the bounds:

  • Stop classes: TaxonNode, FeatureTreeNode ... (All node types in hierachies?)
  • ReferencingObjectScopes: This would be a project specific scope definition. For Phycobank the scope would encompass all nomenclaatural acts (Names, TypeDesignations) which belong to the same Registration.
  • ... other ?

But what if the name of a Genus is being changed? we can't stop in this case, all taxonomic children would need to be taken into account.

... To be continued ....

X.3) unnoticed accidentally changing of second level referencing objects

refers to C)

A user changing an author may be aware of the fact that the reference in which this Person is being used will be modified. But the reference may be used in further contexts. This could lead to unnoticed modifications.

The here described potential risk especially occurs in situations where the user is notified about the first level referencing objects that will be affected by the change. This conveys a security to the user which is not really given. Therefore solutions relying on the users decision are not appropriate.


Related issues

Related to EDIT - feature request #3709: [E+M][Editor] sufficient rights management for E+M workflowResolvedAndreas Müller

Actions
Related to EDIT - bug #6886: Entity creation for users having only CREATE may fail in long running conversationsDuplicateAndreas Müller

Actions
Related to PhycoBank - bug #6185: prevent from erroneous author or reference changesClosedAndreas Kohlbecker

Actions
Copied to EDIT - feature request #6867: explicitely assign and revoke UPDATE & DELETE permission per enitity in the registration workflow ClosedAndreas Kohlbecker

Actions
Actions #1

Updated by Andreas Kohlbecker over 9 years ago

  • Keywords changed from permission security to permission,security,Euro+Med,Migration
Actions #2

Updated by Andreas Müller about 7 years ago

  • Description updated (diff)
Actions #3

Updated by Andreas Kohlbecker almost 7 years ago

Actions #4

Updated by Andreas Kohlbecker over 6 years ago

  • Tags changed from permission, security, euro+med, migration to permission, security, euro+med, migration, phycobank
  • Private changed from Yes to No
Actions #5

Updated by Andreas Kohlbecker over 6 years ago

  • Status changed from New to In Progress
  • Priority changed from Priority14 to Highest
  • % Done changed from 0 to 10
  • Severity changed from critical to blocker
Actions #6

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #7

Updated by Andreas Kohlbecker over 6 years ago

  • Status changed from In Progress to Feedback

I think solution A) as described above is the best idea so far we had.

What do you think Andreas M?

Actions #8

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #9

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #10

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #11

Updated by Andreas Müller over 6 years ago

  • Description updated (diff)
Actions #12

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)

After sleeping one night over it, i came to the following conclusions:

  • A) This approach is not appropriate in the context of applications like phycobank where entity must stay editable as long as the registration process is not completed, this can take several weeks.
  • B1) The only really reliable strategy and maybe not so extensive in terms of computation as initially assumed.
  • B2) Elegant and simple, but it might cause problems and conflicts in phycobank. An example for problems that would arise: A registration for a publication with multiple new names whereas the authors of the name differ from the publication authors. The name X has the authors A and B whereas the article is published by the authors A, B and C. A and B have two referencing objects in this case and are blocked.
Actions #13

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #14

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #15

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #16

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #17

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #18

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #19

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #20

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #21

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #22

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #23

Updated by Andreas Kohlbecker over 6 years ago

After an in depth discussion we decided that for phyconbank the strategy D) (per instance UPDATE & DELETE permission) would be the most appropriate:

  • a submitter will the per instance UPDATE+DELETE permission when he creates a Reference, TeamOrPersonBase, Name instance.
  • once a registration is set to the states rejected, ready or published the UPDATE+DELETE permission must be revoked again, so that the registered name and references are protected from being changed after the editing registration workflow has ended.

The RegistrationStateManager (#6655) could therefore be responsible for revoking authorities. Assignment of authorities however should not be managed in this state machine.

Actions #24

Updated by Andreas Kohlbecker over 6 years ago

  • Copied to feature request #6867: explicitely assign and revoke UPDATE & DELETE permission per enitity in the registration workflow added
Actions #25

Updated by Andreas Kohlbecker over 6 years ago

  • Related to bug #6886: Entity creation for users having only CREATE may fail in long running conversations added
Actions #26

Updated by Andreas Kohlbecker over 6 years ago

  • Related to bug #6185: prevent from erroneous author or reference changes added
Actions #27

Updated by Andreas Kohlbecker over 6 years ago

  • Target version changed from Euro+Med Migration to Release 4.11
  • % Done changed from 10 to 40
Actions #28

Updated by Andreas Kohlbecker over 6 years ago

  • Status changed from Feedback to In Progress
Actions #29

Updated by Andreas Kohlbecker over 6 years ago

  • Priority changed from Highest to Priority13
  • Target version changed from Release 4.11 to Reviewed Next Major Release
  • Severity changed from blocker to normal

The very important task is now being managed in #6867 this issue here therefore is no longer really pressing since it merely only contains all the thoughts on the strategies that have been discussed. Therefore I am lowering the severity and priority and I am moving the ticket to the reviewed ones. But what about the status. It is no longer in progress but also any other status doesn't fit for a such ticket on hold.

Actions #30

Updated by Andreas Müller about 5 years ago

  • Priority changed from Priority13 to Priority10
Actions

Also available in: Atom PDF