Re-enable group permissions support

[jamoore]

This ticket is the story umbrella for all the permissions improvements planned for milestone:OMERO-Beta4.2 in order to re-activate group-sharing. Linked tickets are available under [WorkPlan/Permissions]

Items under discussion

The following items are not listed on the WorkPlan page. If they are deemed important for 4.2, they should be moved there. If not, they should either be deleted or moved to their own tickets.

• thumbnails, annotation links, etc. become a new type of object: "shared" (or similar) which don't prevent delete.
• In some cases, automatically convert object's group to the attached to object? (From #1171, is this necessary if other groups are not visible?)

---

See also:

• ​http://openmicroscopy.org/community/viewtopic.php?f=4&t=306
• ​Aug 21 conf call
• ​Sep 04 conf call
• #1171

[jburel]

GUI

• Login: if a user is member of more than one group, data of the last selected group

will be presented. User will then have ability to switch to another group.

• user able to see data of other users if the status of the group is "visible".

[jmoore]

From ​Sep 04 conf call:

 - permissions (Brian)
  -- private space, and a single or multiple public space?
  -- fine for vast majority of people
  -- private space gets rid of PI concept. perhaps via 600
  -- Donald: no private space?
  -- Brian: can you add more than one boss?
  -- Chris: how does this work with the setting a group to public from private?
  -- quickest option:
   --- uesr only in one group
   --- turn group private or public
   --- server ensures graph-consistency, both group_id and permissions
   --- PI or admin can move group to public
   --- UI: need to know group prespective (don't show data)
   --- ADMIN UI: need to allow upgrade to group visible. can't downgrade
    ---- offering upgrade button
    ---- sending email to all the users??
  -- next stage: either private space or multiple groups.
  -- really a testing issue: moving the component/client tests.
   --- get them green
   --- then modify them as expected

[jmoore]

Moving as discussed ​conf call 2009-09-18

[jmoore]

Brief discussion on write with Ola, Josh, Jean-Marie:

• want to keep things simple for the user
• the solution above allows setting on group
• but do we need to let user change write-ability?
• e.g. "make container read-only or full-access"
• J-M: dangerous except for annotations to let change
  • Josh: but Image.description or Shape.color?
• "rwrwrw" not a good idea. But could have a PUBLIC group (with guest)
• for options of groups: rw, rwr, rwrw
• configurable initial groups? Maybe
• users in more than one group? Yes
• more than one PI? Yes
• G/E/P/D/I? Yes, but G is strict (security based), E isn't (could be mixed)
  • Need a way to restrict owner-mixing? Maybe (would be LINK permission)
  • Perhaps handle it via best-practice
  • Possible to distinguish hierarchies and annotations? Hard.
  • Possibly use color codes per user initially.
  • If user filtering, pass back "friend" user list of who was queried?

[jmoore]

Marked tickets #1072 and #1171 as duplicates.

[jmoore]

Maked #203 as a duplicate of this ticket.