New Role

[pwalczysko]

see https://trello.com/c/t0nT7KYa/133-new-role#comment-57f4f24eac9fdd7102327437. Accompanying tabular explanation Accompanying power point presentation

This is an attempt to design the New Role (LightAdmin, people like Importer, Analyst, User Organizer and similar) from the user perspective. The trello card above encompasses the technical back-end part of the problematics and defines some restrictions of and Admin in OMERO (these restrictions make him then a LightAdmin, without the right to do everything in OMERO, but leaving him some extra, server-wide rights).

The extra rights (properties) up till now (depending on the progress of @mtbc who is creating further such rights atm, noted as "envisaged" in the table below) can be defined as:

1. Chgrp
2. Chown
3. ModifyUser
4. ReadSession
5. Sudo (needed for ImportAs)
6. WriteFile (necessary for ImportAs, right to write files into ManagedRepo). Nevertheless, removal of this right does not completely protect deletion of original files. Also, workflows of ImporterAs not using Sudo tend to be clanky. Suggestion is to use this permission only hand-in-hand with WriteOwned.
7. WriteOwned (right to create other people's database items, needed for organizing other peoples data)
8. ModifyGroup (envisaged)
9. Upload Official Script (envisaged)

Based on these rights I would suggest to construct following "New Roles":

1. Analayst. Needs to access, analyse and store the results (including new images) in any group. He might need to store the results in such a manner that they belong to the owner of the original image. As the results might be images which need the import to OMERO, the Sudo feature is necessary here too. Optionally we can offer curtailing the right to delete other peoples database items like P/D and curtailing the right to delete other peoples original data for this role. Rights of Analyst: WriteFile (6.), WriteOwned (7.), Sudo (5.), Upload (and Run) Official Script (9.)

2. Importer. Basically imports data of anyone to any group which he is not a member of. Needs WriteFile and Sudo because of the import, but also the WriteOwned in order to create P/Ds for the imported images. Optionally we can offer curtailing the right to delete other peoples database items like P/D and curtailing the right to delete other peoples original data for this role. Chown and Chgrp can come handy for this person in case he/she has no right to delete already erroneously imported data. Chown and Chgrp in right can be optional for this type of person (user can create an Importer role both With and Without the right to Chown and Chgrp) Rights of Importer: WriteFile (6.), WriteOwned (7.), Sudo (5.), Chown (2.), Chgrp (1.)

3. User organizer: Can create and modify users (names, loginnames, email addresses etc.) and also add/remove users to from groups. Can also create new groups. Optionally, this role can acquire the power to Chown and Chgrp, if the users-to-be-shuffled have data-to-be-moved or data-to-be-chowned Rights of User organizer: ModifyUser (3.), ModifyGroup (8.), Chown (2.), Chgrp (1.)

4. Group organizer: Can create and modify groups (putting existing users into existing and new groups). This is a "User organizer" role above, just without the right to create and modify the users themselves. Optionally, this role can acquire the power to Chown and Chgrp, if the users-to-be-shuffled have data-to-be-moved or data-to-be-chowned Rights of Group organizer: ModifyGroup (8.), Chown (2.), Chgrp (1.)

5. Any other combination of above and more: The 9. categories/rights/permissions in the first list in this table can be reorganized into any other fitting New Role, such as "Data organizer", "Data and user organizer" etc. as needed by the particular institutions.

@mtbc @joshmoore @jburel @gusferguson @kennethgillen

[pwalczysko]

Discussed with @mtbc about the annotation powers of light admins. Basically, there should be no difference between the linking of Project-Dataset and linking Image-Annoation. This means that when they canLink they canAnnotate (the WriteOwned permission is necessary for this). This is possible in RW, RA and RO groups but not private groups. Will investigate the annotation behaviour further (can light admin create new Tags, File Annotations (in a group he is not a member of, which is the default for light admins).

[pwalczysko]

@will-moore :

Presumably this would also remove annotations etc?

As @mtbc expected, and my new two tests for Chgrp and Chown show, the Chown and Chgrp permissions are fully equipped and self-sufficient to do whatever it is they need to do. I.e. when the Chgrp or Chown action needs for its execution to sever some links, it will do so, no additional permissions needed (e.g. move an image included in a dataset to another group, or Chown an image included in a dataset to somebody else in private group).

[pwalczysko]

@will-moore : The last test shows that for adding a File Attachment (wich Original File) to an image, the light admin needs WriteOwned and WriteFile permissions. This workflow is very important for any image analyst (the results will be delivered by him/her and uploaded to OMERO as file attachments. Also, the analyst will need sometimes to be able to import new images for them (for which he/she needs WriteManagedRepo as well). He will be unlikely to use Sudo though, as these processes might be run as part of his scripts. I would suggest we need to add another layter in your bullet point list just after - Write Owned [You can create, edit & link other users' data], namely

• WriteFile & WriteManagedRepo (you can upload (assuming you have WriteOwned as well) File Attachment (results of analysis) and import an image not using Sudo)

[pwalczysko]

@will-moore : Note that your second bullet point Write Owned [You can create, edit & link other users' data] should be probably now put more precise as Write Owned (You can create, edit & link and annotate other user's data except file annotations (but including Tags, MapAnnotations..., ROIs and Rnd settings). Nevertheless, linking and annotating (which is principally linking the annotations) CANNOT be done in private groups.

[will-moore]

As discussed with @pwalczysko, it probably makes sense to group WriteOwned, WriteFile and WriteManagedRepo into a single checkbox in the UI, since there isn't really a case for needing these roles in isolation. Similarly for DeleteOwned, DeleteFile and DeleteManagedRepo.

[mtbc]

@pwalczysko points out that as ModifyGroupMembership allows light admins to make normal users into group owners then those are possibly more powerful than the light admin. For example, they may be able to delete data that the light admin cannot. If or how best to address this is not yet clear to me.

[jburel]

@mtbc @pwalczysko is that really an issue? I can see a light admin, making a PI a group owner so he/she can manage the users in the facility without having to go back to the administrator of the system

[mtbc]

Mmm, hence my "if". :smiley:

[pwalczysko]

@mtbc @jburel : Yes, agree, in the first instance, we should just let it be as it is, and explain the feature. There is nothing wrong per se with the workflow, it was just a "gotcha" for me I did not think about before.

[pwalczysko]

@will-moore @mtbc @jburel : Note on ModifyGroupMembership: When this is the only permission which the light admin has (all the rest is forbidden), then the Web UI cannot be used for adding/removing of the users from groups, because it is probably trying to update the user/group, which is throwing securityViolation, as the light admin does not have the ModifyUser and ModifyGroup permissions.

The CLI is in this case absolutely fine though. The ModifyGroupMembership role in isolation (without the ModifyUser and ModifyGroup) has sense when using the CLI, but not Web. For Web, we would have to give the ModifyUser as well as ModifyGroup permissions additionaly.

[pwalczysko]

Further note on ModifyUser, ModifyGroup and ModifyGroupMembership. It turned out again when testing the ModifyGroup privilege in isolation that the user has a poor experience in Web (some red message saying "you are not an admin or owner of the group" but then the action proceeds !). So I might try to formulate in the doc something like :

If your newly created Admin with restricted privileges plans to use Web UI for user/group administration, give always all three ModifyUser, ModifyGroup and ModifyGroupMembership, when you create this Admin. 

[mtbc]

For making privilege elevation prohibition more obvious client-side (when I get the enforcement working!) might want to gray out any privileges that rely on anything not included in the admin service's getCurrentAdminPrivileges().