[ome-users] OMERO clients user's comments

[josh.moore at gmx.de]

Caterina Strambio De Castillia writes:
 > Dear OMERO developers,

Caterina,

a few questions if I (we) may to comments 1 & 2. Delete is one of our
perennial issues. We wrestle with it ourselves, over and over again. I
think even just your comments show how complicated it can be.

In the simplest case, the user should be able to delete things
him/herself as can an admin. *Unless* GLP/provenance restrictions
require it to stick around OR another user has linked to that data
making it somehow shared.

We have discussed the concept of the delete-basket, and having some
workflow to pass that off to the administrator with the request
"please delete" is an interesting idea.

When implementing delete as it currently stands, though, the biggest
hurdle for me was understanding the "classification of deletable
types". Based on configuration, there are things that only admins can
delete (users, for example), that only admins & users can delete
(projects, datasets and maybe images), and things that one user can
delete for another, say the owner of an image can force another user's
thumbnails & rendering settings to be deleted.

So, to finally get to my questions, 

 * did you notice any other classes of things to be deleted while you
   were doing your review?

 * rather than configuration by types, would it suffice to have a few
   "profiles" -- GLP1, HIGHSECURITY, OPEN, etc. -- which apply at the
   db instance level?

 * would you ever need to remove a user but keep his/her data?

 * what other actions would you want to see when removing a user?
   "Give data to user X", "Transmit to server Y", etc.

Once again, thanks for all the feedback.
~Josh.

 > 1) OMERO.webadmin:
 > 
 > Administering scientists and groups
 > 
 > * COMMENT_1: I think it is important to allow admin more
 > flexibility in the administration of users (i.e. scientists) and
 > user's data Specifically admin should be able to remove user and
 > user data from data base.  For what I can tell only a user without
 > data can be deleted. This makes sense obviously but a real-world
 > systems will require more flexibility.
 > 
 > Possible scenarios that would require such a measure:
 > 
 > When a user leaves a facility and his or her data need to be
 > migrated to a new site.  During testing In case of user's mistakes
 > (especially likely to happen during large data migration or at db
 > first instance installations) Insertion of "garbage data" in the db

 > At preset beta3 does not appear to allow users data to be deleted (in  
 > case it is there I did not find it).
 > 
 > 		TWO POSSIBLE SOLUTIONS: either data should be erasable
 > at admin side or at user side or both. This option should be set
 > depending on the needs of each OMERO.db instance
 > implementation. One possible GLP- compliant implementation is
 > suggested below.
 > 
 > 2) OMERO.insight:
 > 
 > Administering image data hierarchical organization, data-sets and  
 > projects
 > 
 >   * COMMENT_2: (related to comment regarding admin flexibility):   
 > There has to be flexibility on the USER side on managing image data.  
 > I argue the user has to be able to remove data from the database, for  
 > example, in case of errors she/he made during import or in case of  
 > failed import executions.
 > Obviously, care should be taken in implementing DATA deletion from DB  
 > in order to comply to good laboratory practices (GLP) and ethical  
 > concerns.
 > 
 > 		Possible controlled implementation of DATA deletion by
 > user: USER moves it to "to be deleted" dataset or folder or other
 > container and then admin delets upon permission from group owner or
 > group leader.  This would prevent accidental deletion of image data
 > and malicious deletion of "not wanted" data. Specific options
 > should be set depending on level of security privileges of
 > individual user.