Light admins doc #1617
Light admins doc #1617
Conversation
|
#1617 (comment): I don't yet know. |
| ------- | ||
|
|
||
| An administrator with restricted permissions is a way to cater for the need for more powerful users. In the real world, these will typically be imaging facility managers, image analysts, or anybody who needs to organize users and data in OMERO. The only other way how to create users with necessary powers for abovementioned actions would be to create new administrators in OMERO, which is not advisable for security reasons. Administrators with restricted permissions can be created and and their permissions tailored for the task they are meant to perform on behalf of other OMERO users. | ||
|
|
There was a problem hiding this comment.
Suggested alternative first sentence: "OMERO allows you to create administrators with a subset of the full administrator privileges".
"...anybody who needs to organize users and data in OMERO". Everyone needs to organise data in OMERO. Needs to emphasise that this is not bound by usual groups permissions.
I think you can remove the sentence "The only other way...."
|
|
||
| An administrator with restricted permissions is a way to cater for the need for more powerful users. In the real world, these will typically be imaging facility managers, image analysts, or anybody who needs to organize users and data in OMERO. The only other way how to create users with necessary powers for abovementioned actions would be to create new administrators in OMERO, which is not advisable for security reasons. Administrators with restricted permissions can be created and and their permissions tailored for the task they are meant to perform on behalf of other OMERO users. | ||
|
|
||
| Typically, a full administrator in OMERO would create new administrators with restricted permissions using OMERO.web interface (hook to Help with Webadmin graphic screenshots) |
There was a problem hiding this comment.
Suggest: "Full administrators in OMERO can create new administrators with restricted permissions using the OMERO.web interface".
|
|
||
| Typically, a full administrator in OMERO would create new administrators with restricted permissions using OMERO.web interface (hook to Help with Webadmin graphic screenshots) | ||
|
|
||
| We suggest here 4 setups that should cover the 4 most mainstream workflows. Please note that it is fully possible to combine the permissions (check the checkboxes in the OMERO.web interface) in any way you see fit. The permission groupings were designed in such a way that they still bear useful functionality even when used in isolation. For example checking the Chown checkbox will indeed give the new administrator with restricted permissions the power to change (transfer) ownership of other users' data with no other ifs and buts. Nevertheless, please od not expect for any workflows mentioned here that all OMERO.clients (OMERO.web, OMERO.insight, command line interface (CLI)) are fully equipped to execute them (see details below). New features will be added in OMERO.clients in 5.3.x series of OMERO releases. |
There was a problem hiding this comment.
typo: "please od not expect". Add 'the' to "in the 5.3.x series"
|
|
||
| We suggest here 4 setups that should cover the 4 most mainstream workflows. Please note that it is fully possible to combine the permissions (check the checkboxes in the OMERO.web interface) in any way you see fit. The permission groupings were designed in such a way that they still bear useful functionality even when used in isolation. For example checking the Chown checkbox will indeed give the new administrator with restricted permissions the power to change (transfer) ownership of other users' data with no other ifs and buts. Nevertheless, please od not expect for any workflows mentioned here that all OMERO.clients (OMERO.web, OMERO.insight, command line interface (CLI)) are fully equipped to execute them (see details below). New features will be added in OMERO.clients in 5.3.x series of OMERO releases. | ||
|
|
||
| Note on group allegiance: All the workflows here do not assume that the administrator with restricted permissions is not a member of any group except the System group. This does not preclude such administrator from being a member of any number of groups though, just as any other user, and still be able to perform his/her workflows dealing with other users' data in the groups which he/she is not a member of. See note on OMERO.insight in the Worfkflow 1 below though (hook to Workflow 1). |
There was a problem hiding this comment.
I think you've got a double negative: I think you want "the workflows here assume that..." OR "administrator with restricted permissions is a member of..."
There was a problem hiding this comment.
Reformulated this Note completely.
|
|
||
|
|
||
| =============================== ======================= ======================= ===================== ======================= | ||
| OMERO.web interface checkbox Data viewer Importer Analyst Group and Data Manager |
There was a problem hiding this comment.
Maybe first column name should be "Required privileges"?
|
The main text is finished. Also the glossary and the terms are done and Notes are created. The only ToDos here as for now I left
Maybe also if you can say what other linkages might be done I did not think of (some more Balaji's videos @bramalingam , more relevant docs, etc.) As indicated, it will be built on https://www.openmicroscopy.org/site/support/omero5.3-staging/sysadmins/admins-with-restricted-privileges.html |
| Summary | ||
| ------- | ||
|
|
||
| OMERO allows you to create administrators with a subset of the full administrator privileges. This is a way to cater for the need for more powerful users acting on behalf of all other OMERO users, with no group allegiance but with access to all groups and data of all users in OMERO. This should be achieved without creating new full administrators in OMERO. In the real world, these administrators with restricted privileges (restricted admins) will typically be imaging facility managers, image analysts, or anybody who needs to organize users and data of others' in OMERO. |
There was a problem hiding this comment.
These are tremendously long lines. Could we wordwrap please?
|
|
||
| Full administrators in OMERO can create new administrators with | ||
| restricted privileges using the OMERO.web | ||
| interface (hook to Help with Webadmin graphic screenshots). |
There was a problem hiding this comment.
I would use :help:<sharing-data.html#admin>` as the reference here - we can add an extra step in between the current steps 2 and 3 for creating these new admins and using an existing anchor means the link won't be broken until the live help is updated at the release
|
All links added. There is nothing on my ToDo list atm for this PR. Ready for re-review. |
| In the real world, these administrators with restricted privileges | ||
| (restricted admins) will typically be imaging | ||
| facility managers, image analysts, or anybody who needs to organize | ||
| users and data of others' in OMERO. |
|
|
||
| Full administrators in OMERO can create new administrators with | ||
| restricted privileges using the OMERO.web | ||
| interface, see :help:`create new users <sharing-data#admin>` chapter |
There was a problem hiding this comment.
Also 'section' might be better than 'chapter' as this is just a subsection.
| be added in OMERO.clients in the 5.3.x series of OMERO releases. | ||
|
|
||
| .. note:: | ||
| **Group allegiances** All the workflows here do not assume that |
There was a problem hiding this comment.
do we talk of memberships as "allegiances" elsewhere?
There was a problem hiding this comment.
Not that I can think of. I'd go with 'membership' instead
There was a problem hiding this comment.
I'd also recommend membership in all cases.
| the administrator with restricted privileges is not a member of | ||
| any group except the System group. This does not preclude such | ||
| administrator from being a member of any number of groups. | ||
| Inside the groups the restricted admin is a member of, he/she |
There was a problem hiding this comment.
I'm all for singular "they" but @hflynn may differ!
There was a problem hiding this comment.
Singular 'they' is good for me too
| administrator from being a member of any number of groups. | ||
| Inside the groups the restricted admin is a member of, he/she | ||
| has the same privileges as other group members of that group | ||
| additionally to his/her adminstrative privileges. |
| than the sudoing restricted admin, these lesser privileges will apply | ||
| also for the restricted admin as long as sudoed-in. | ||
| Creation of a restricted admin with higher privileges than the creator | ||
| or creation of a full administrator are prevented. Furthermore, although |
There was a problem hiding this comment.
maybe enclose "or creation of a full administrator" in commas? (also "and" rather than "or") otherwise I wonder about higher privileges than the creator of a full administrator
| of that user. When the restricted admin is working on | ||
| behalf of a user and using Sudo, their privileges are a common least | ||
| denominator of the privileges of the user and of the restricted | ||
| admin. See also Note on privilege escalation, |
There was a problem hiding this comment.
maybe Sphinx allows us to link to these
There was a problem hiding this comment.
Unfortunately, not, consulted with @rleigh-codelibre
|
This should address all the comments. |
|
Reads nicely and should give users a good idea of permissions and behaviour of clients etc. |
|
Following today's discussion with @pwalczysko @mtbc and @joshmoore |
|
Last commit deals with the dropped fieature of importing into not-your groups. See reasoning in https://trello.com/c/RQLsMkEV/14-fix-import-into-other-groups |
| data and to link the data to those containers or to already | ||
| existing containers owned by the new owner. Note that any links created by | ||
| the Organizer will belong to the Organizer, not the owner of the data. This | ||
| will be addressed in OMERO.web in the 5.3.x series. The ownership transfer |
| It is recommended to always grant all three :term:`Create and Edit Groups`, | ||
| :term:`Create and Edit Users`, :term:`Add Users to Groups` privileges | ||
| to prevent poor experience in the OMERO.web client. | ||
| These OMERO.web issues will be addressed in the 5.3.x series. |
| - CLI: Upload of official scripts is allowed (in any group type, | ||
| see :doc:`/developers/scripts/user-guide` and below). | ||
| Upload of attachments with results, annotating | ||
| (not in private group), creating containers, import of resulting images |
There was a problem hiding this comment.
Revise: is this possible ? See Mark's PR
There was a problem hiding this comment.
Possible, checked. Care has to be taken in private groups (without chown the owner of the original data will not see the images which Analyst (light admin) imported for them, because these images belong to Analyst.
Clarification added to doc.
| # Create new Dataset | ||
| $ bin/omero obj new Dataset name=new-dataset | ||
| # Import result images into the Dataset | ||
| $ bin/omero import -T Dataset:name:new-dataset /PATH/TO/RESULT/IMAGES |
…ImportAs workflow
…sudo in not-your-group
| # Move a Dataset to a group where the prospective owner is member | ||
| # and include all annotations on objects | ||
| # linked to that Dataset even if they do not belong to the same user | ||
| $ bin/omero chgrp 5 Dataset:51 --include Annotation | ||
| # Transfer ownership to user 55 of the whole hierarchy of the Project 112 | ||
| # including the links, as long as all the objects and links in the | ||
| # hierarchy belong to the same user |
There was a problem hiding this comment.
@mtbc : Expected behaviour here is that in RA and RW groups, the annotations on the hierarchy will not be transferred, but stay with the original user. This does not depend on whether or not the owner of the data is in the group, does it ?
Second question: Chgrp of a Dataset as described above 753f70c#diff-dc981c0425062d2436a7cf30eff329f7R353 is going to behave as described if all the Datasets and Images and links belong to the same user (annotations do not have to, I chacked, the --include will override all). But what if an image (with annotations) in that Dataset belongs to somebody else ? Will the Chgrp procced as described ?
There was a problem hiding this comment.
in RA and RW groups, the annotations on the hierarchy will not be transferred, but stay with the original use
I'm sorry, I'm completely lost here. With Chgrp2 even transferred things stay with the original user. Moving from RA to RA groups where "all the objects and links in the hierarchy belong to the same user" does typically transfer annotations unless they are also on data that is being left behind. I'm not sure if "the group" here is source or destination but if the Chgrp2 is going to happen at all then after that point group membership of data owners mostly doesn't matter. For moving annotations the main differences are,
- basic and comment annotations are treated one way, attachments and tags another, and others like map annotation fall in the middle
- it can matter if the annotation is owned by the person who also owns the annotated data
- it matters if the move is to a private group
but then there are also special rules like in a RA group if I tag my image with your tag then now you can't move that tag to another group. The behavior is some mix of what seemed not unreasonable and what satisfied the legacy integration tests.
I think mixed-ownership container hierarchies might indeed all move in RW groups and an image owner's own annotations will tend to move with an image. It might be that other users' annotations also move if it is a group owner doing the moving.
So, it probably does depend rather on the specifics: in pursuit of https://trello.com/c/8l3d5N5K/93-test-more-annotations-moves you might want to try creating an integration test to probe the particular corner of interest as AnnotationMoveTest goes only so far and even HierarchyMoveAndPermissionsTest.testMoveRois doesn't cover all these equivalent cases for ROIs.
There was a problem hiding this comment.
The <!-- ... --> comments in blitz-chgrp-rules.xml may be helpful too. There is something of a summary (probably not too much out of date) in the Chgrp2 section of https://docs.google.com/document/d/1kVAqJ5imXfEPWAZVtLwQxdb5VRkGfRN5NXr_JKYLl1o/edit.
There was a problem hiding this comment.
@mtbc : Thank you. Sorry for the confusion, I shoiuld have not asked in such complicated way. I had 2 questions, the first one concerning the chown (you thought I am asking about chgrp which confused you, sorry about it). Only my second question was about chgrp
There was a problem hiding this comment.
Heh, yes, chown is generally quite reluctant to propagate changes down the graph to objects owned by a different user; generally their group memberships won't matter for that.
|
@pwalczysko you won't have to do anything |
|
Safe to merge now? |
|
Safe and FMPOV desirable to merge. Not that this is the end of those changes, as we are still fine tuning the functionalities. But this PR has 100-eds comments reviewed and the conversation is unwieldy. Will open separate PRs to catch up with the improvements of the code later as these improvements come and are confirmed. |
|
Merging now that |
See trello card comment for context.
Also useful links are
Power Point presentation with features slide-by-slide
g.doc tables
github issue
new roles PR
Web UI PR
There were some comments from @jburel @will-moore and @mtbc already which I tried to incorporate here.
It is still work in progress, the Workflow 4 is just drafted, the links to other docs are not there, and Glossary is just hinted to.
The purpose of this PR atm is to get common platform to discuss and to overcome the hurdles of Sphinx and formatting asap.
Built at https://www.openmicroscopy.org/site/support/omero5.3-staging/sysadmins/admins-with-restricted-privileges.html