feature request #4305
Updated by Andreas Müller 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** 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@} **B1) **B) no further referencing object of other users** object** 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 (B) is not feasible since it would be required to also check the next level referencing objects and so on, in fact it is needed to check the whole tree of referencing objects until the process reaches objects at the tips of the branches which are editable by the user. This solution might be too extensive in terms of computation, even if this walk along the referencing objects tree only is required when a user only *UPDATE* is needed and the user only is having *CREATE*. **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. 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 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 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.