feature request #4305
Updated by Andreas Kohlbecker over 6 years ago
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 following solutions: ## A) continuedCreationTimespan **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) **B1) no further referencing object of other users 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) **B2) no further referencing objects 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. 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. 1. 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 changes 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 In reality it seems to be much more important if an object is only referenced once or multiple times*. 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' 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. Using cloned objects, however imposes more complexity on the UI development. Let's take a look at the following example for illustrating this: