[ome-users] OMERO clients user's comments

[josh.moore at gmx.de]

Hi Caterina,

Caterina Strambio De Castillia writes:
 > Dear Josh,
 > thank you for the comments.
 > I totally appreciate the difficulty of the issue.

That's good to hear. Our use of the trash icon on the desktop has
unfortunately taught us to think deletion is for the most part solved.

 > In general, I think for the system to be usable and actually used,
 > the bottom line has to be CONTROLLED_FLEXIBILITY. There has to be a
 > way at ADMIN level to be able to do most things on DATA USERS
 > GROUPS ETC.  Obviously with previous discussion from OWNER of DATA
 > and this is the key issue, how do you implement this?

True.

 > There has to be COMMON SENSE and also I firmly believe that too much  
 > MANAGING from the TOP (especially if not controllable at each db  
 > instance) will strongly deter use. Biologists are a very independent  
 > minded bunch of people and the rarely like being told what to do.

Also, true. :)

 > Now to your questions:
 > I answered most and asked for a clarification on one.
 > 
 > Do not hesitate to contact me in case of further questions or  
 > clarifications.

Naturally! :)

 > Best
 > Caterina
 > 
 > > \
 > >  * did you notice any other classes of things to be deleted while you
 > >    were doing your review?
 > >
 > 
 > Classes of objects to be deletable and edited:
 > 
 > COMMENTS, TAGS, ATTACHMENTS: they need to be erasable (they are  
 > already) and MOST OF ALL there is a need to be able to EDIT and  
 > UPDATE_ I had problems with this, I noticed that if I changed a  
 > comment the old comment was still present kind of wiki style. This  
 > might be useful but there has to be an option for simple editing as  
 > one may not want to keep all of the comments one ever made on an  
 > image. Some of the comments maybe needed only transiently, for  
 > example in case one is looking for images to use for a presentation  
 > or to show a colleague...
 >
 > RENDERING HISTORY INSTANCES: these clearly need to be deleted in case  
 > the list becomes too long and one settles on a way of looking her/his  
 > images (the data is not affected).

Ok. Then we are generally thinking about the same types. This is good
to hear. If anyone has other types, please speak up.
 
 > >  * rather than configuration by types, would it suffice to have a few
 > >    "profiles" -- GLP1, HIGHSECURITY, OPEN, etc. -- which apply at the
 > >    db instance level?
 > >
 > 
 > can you explain better what you mean here as I think this is a  
 > central issue,
 > 
 > In general, at db instance level there has to be a way for ADMIN to  
 > configure DELETE-ACTIONS sets depending on the END-USER needs for the  
 > individual db instance.

Perhaps the question comes down to how configurable this needs to
be. I can imagine a spectrum (going from least to most configurable --
or simplest to most complex if you prefer):

 * omero.delete.profile={GLP1,HIGHSECURITY,OPEN}
   ----------------------------------------------
   Each of these is probably a class in the server, which someone has
   to code. Not very configurable, but easy to use.

 * omero.delete.image=<configuration>
   omero.delete.tag=<configuration>
   OR
   omero.delete.myUser1=<configuration>
   omero.delete.myUser2.tag=<configuration>
   ----------------------------------------
   Now you are specifying a mapping from either types or users/groups
   to some configuration.

 * omero.delete.myUser1.image=<configuration>
   omero.delete.myUser1.tag=<configuration>
   omero.delete.myUser2.tag=<configuration>
   ----------------------------------------
   Now you are getting into a full mapping. This is quit complicated
   and I don't even know if this is something we would consider.


Most likely, the simplest possible approach that would work should be
chosen, but if a site needs to develop there own code, that would be
possible, too.

 > 
 > >  * would you ever need to remove a user but keep his/her data?
 > >
 > 
 > YES there might be a need, in case a lab-member_SCIENTIST leaves a  
 > lab_GROUP, the group leader will keep his/her images, in this case  
 > though the group-leader_GROUP-OWNER most likely would want to keep  
 > the images available "under" the lab member name, this way the images  
 > would be much more likely to be retrievable as "associated" to a person.

Understood. This would probably then be "deactivating" a user. All the
data would still be properly linked.

 > BOTTOM LINE: there need to be flexibility and I think the solution  
 > has to be found in the GROUP-OWNER interacting with ADMIN and finding  
 > a way of dealing with each situation. As a consequence, ADMIN has to  
 > have the ability of DELETING USERS with data, DELETING USER's DATA,  
 > DELETING USER but not DATA (this would require migrating his/her DATA  
 > to another SCIENTIST.
 > 
 > One possible real life scenario: somebody working on related project  
 > (not usually group-leader) in the lab will migrate data and then  
 > communicate to the ADMIN the user is safe to DELETE.

Ok. In principal this is straightforward, but there are corner cases
which can get nauseatingly difficult. So, give us some time. :)
Imagine for example a user who is in two groups. If the target users
for the data are not also in the same two groups, some data may become
"invisible". Again, you are right, then the administrator needs a
FLEXIBLE way of dealing with that.

 > >  * what other actions would you want to see when removing a user?
 > >    "Give data to user X", "Transmit to server Y", etc.
 > >
 > 
 > All of the above plus "move to ARCHIVE" data has to be kept somewhere.

What should an ARCHIVE look like? An export (OME-TIFF?) of the image
plus what metadata? How far does one go? The user's annotations? Other
users' annotations? This brings up the fact that export and delete are
very closely related.

 > This makes me think of a possible BASIC rule: in general DATA (except  
 > for garbage  data which is fruit of USER or SOFTWARE mistakes) should  
 > only be deleted if moved to another USER, another db-instance or  
 > ARCHIVE.

I think that's sound.

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

Cheers,
~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.