Page Contents

OMERO

Downloads
Feature List
Licensing

Previous topic

Known limitations

Next topic

Basic UNIX (and UNIX-like platforms) server installation

This Page

Groups and permissions system

In the 4.4 release of OMERO, the groups and permissions system was revamped to allow users to share data with more control. Users can now move data between groups that they are a member of.

Summary

A user may belong to one or more groups, and the data in a group may now at most be shared with users in the same group on the same OMERO server. The degree to which their data is available to other members of the group depends on the permissions settings for that group. Whenever a user logs on to an OMERO server, they are connected under one of their groups. All data they import and any work that is done is assigned to the current group, however the user can now easily copy their data into another group.

Users

Administrator
Your OMERO server will have one or more administrators. Each group can be administrated by any of your server administrators. The administrators control all settings for groups.
Group owner
Your group may have one or more owners. The group owner has some additional rights within each group than a standard group member, including the ability to add other members to the group.
Group member
This is the standard user.

Groups and users must be created by the server administrator. Users can then be added by the administrator or by one of the group owners assigned by the administrator. This would typically be the PI of the lab. The group’s owners or server administrator can also choose the permission level for that group. See the OMERO.insight and OMERO.web admin movies below for more information about groups and how to administrate them in OMERO.

See also

OMERO.insight Admin update in OMERO 4.4
Movie describing the administration tools update under OMERO.insight for OMERO 4.4
OMERO.web Admin update in OMERO 4.4
Movie describing the administration tools update under OMERO.web for OMERO 4.4

Group permission levels

The various permission levels are:

Private

This group is the most restrictive:

  • A private Group owner can see and control who the group members are and can view their data.
  • As a Group member, you will only ever be able to see your own data.
  • This can be used for general data storage, access and analysis, but has very limited collaboration potential other than for the Group owner to see other group members data.

Potential Use-Cases of Private group:

  • This group would be designed so that a PI as Group owner and their student, as a Group member, can access the student’s data. A student might use this as somewhere to store all of their data and from here, the PI and/or student might decide which data could/should be copied into a more collaborative group where additional members would also be able to view the data.
  • For an institutional repository type structure where data are being archived, but not necessarily open for general viewing.
Read-only

This group is the intermediate option that allows visibility of other users and their data, but minimal ability to annotate their data:

  • The Group owner can control group members as above and can perform some annotations on the other group members data.
  • Group member can see who other members are and view their data, but he cannot annotate another members’ data at all.

Potential Use-Cases of Read-only group:

  • A scientist might move data into a read-only group when they want other group members to access and view their data. Other members can view, while the group owners can annotate and/or add Regions of Interest (ROIs) to the other member’s images.
  • For an institutional repository where data are being archived and then available for other users in the institute to view; this could be standard storage of all original data, or for data that is included in publications.
Read-annotate

This is the most collaborative group:

  • Group member can view other members, their data and can make annotations on those other members’ data.

Potential Use-Cases:

  • This could be used by a group of scientists working together with data for a publication.

See also

OMERO.insight Permissions update in OMERO 4.4
Movie describing the permissions update under OMERO.insight in OMERO 4.4
Web Permissions update in OMERO 4.4
Movie describing the permissions update under Web in OMERO 4.4

Changing group permissions

It is possible for the Group owner or server Administrator to change the permissions level on a group after it has been created and filled with data, with the following limitations:

Warning

Please be very careful before downgrading a group’s permission level. If a user has annotated other users’ data and the group is downgraded, any links to annotations that are not permitted by the new permissions level will be lost.

Permissions on your and other users’ data

What can you do with your data?

All OMERO users in all groups can perform all actions to their own data.

The main actions available include, but are not limited to:

  • Create projects and/or datasets.
  • Import data.
  • Delete data.
  • Edit names and descriptions of images.
  • Change rendering settings on images.
  • Annotate images (rate, tag, add attachments and comment).
  • De-annotate (remove annotations that you have added).
  • Use Regions of Interest (ROIs) (add, import, edit, delete, save and analyze with them).
  • Run scripts.
  • Move data between groups, if you belong to more than one group.

What can you do with someone else’s data in your group?

Actions available for you on someone else in your group’s data will depend both on the permissions of the group you are working in, and what sort of user you are. See the table below for a quick reference guide to permissions available on other people’s data.

Some of these policies may evolve as the permissions functionality matures in response to user feedback. Please let us know any comments or suggestions you have via our mailing lists or through the forums.

Permissions tables

The following are the permissions valid for users working on data belonging to other group members. These permissions depend on the group permissions and on the type of the user performing the action.


Key

Action
Action on other users’ data
Annotate
Add annotations (rating, tag, attachment, comment ROI) to another users’ data. Also create & save ROIs (save ROIs that you draw on another users’ data).
Delete
Delete data such as images or ROIs. ROIs may have been added by others or yourself.
Edit
Modify the name or description of other users’ objects such as images.
Mix data

Copy, Move or Remove other users’ data to or from your Projects, Datasets or Screens. Copy, Move or Remove your or others’ data to or from others’ Projects, Datasets or Screens.

Note

You should always be able to remove annotations (such as tags) that you linked to other users’ data (you own the link). The link can be deleted, but the tag itself will not be deleted.

Move between groups

Only the admin has the right to move other users’ data between groups.

Note

The admin does not have to be member of the destination group.

Remove annotations
Remove annotations made by others on your data.
Render
Create your own rendering settings (this will not modify the settings of the owner).
View
View other users’ data such as images. View ROIs added by others. Draw ROIs on other users’ data, but they cannot be saved.

Issues to be aware of

ROIs

  • You can never edit (change text or move) other users’ ROI.
  • Any ROIs added to other users’ data will not affect ROIs added by the owner.

Tags and attachments

  • A tag or attachment is ‘owned’ by the person who creates it or uploads it to the server.
  • The link between a tag or an attachment is ‘owned’ by the person who annotates an image with that tag or attachment i.e. makes a link between the tag/attachment and the image.
  • De-annotation deletes the link between the tag/attachment and image but does not remove/delete the tag or attachment from the system.

Scripts

  • Although all users can run scripts on other users’ data, the actions within those scripts will be subject to the restrictions of the permissions detailed in the tables above.