[ome-users] OMERO clients user's comments

[Caterina Strambio De Castillia]

Dear Josh,
thank you for the comments.
I totally appreciate the difficulty of the issue.

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?

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.

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.

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).


>  * 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.


>  * 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.

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.


>  * 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.

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.


> 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.