Personal tools
  • We're Hiring!

You are here: Home Community Minutes Mini Group meetings Other 2012.03.12-GroupPerms


Attending: Josh, Andrew, Jean-Marie, Chris, Will

The problem (Jan. 27)

We have a number of states that we need to rationalize. I'll go through them from most to least restrictive:


Server: Supported. The data-owner and group-owners can link and edit data

Client: Supported. Only the data-owner can link and edit data

  1. COLLABORATIVE READ-LINK (restricted):

Server: Not supported.

Client: Supported. Group-members and group-owners can only link rendering defs, annotations, etc.


Server: Supported. Group-members and group-owners can make any type of link (dataset-image, etc)

Clients: Not supported.

Note: clients assume that these linkages do not exist, even though a Matlab script for example could break this contract.


Server: Not supported. Only data-owners and group-owners can make edits.

Client: Not supported. Only data-owners can make edits.


Server: Supported. Group-owners can do anything to the data full-link, edit, delete), and can create new users within the group.

Client: Supported. Group-owners can only delete and restricted-link, and can create new users within the group.


Server: Full rights, but can't add users to the group.

Client: Full rights, but can't add users to the group.

To move all of these states server-side, we would need probably need to make use of more permission bits, and quite possibly upgrade the database. To flip between certain states, we could make a server-wide configuration setting. With a bit more work, we could make the configuration per group.

Obviously, if we plan to redesign much of this for 5.0, investing too much time for 4.4 (which I already feel looming over me) might not be the best idea, but feedback both internally and externally will hopefully keep us from making more mistakes.

Thoughts? (since I know you all LOVE this topic)

Initial proposal (Mar.5)

Hi all,

This week I plan to start work on public groups [#2183] at least to the point where we can properly support JCB. After hearing more about what Carlos and possibly other needs (see the email below) as well as watching Dom's presentation, I've been sketching possible changes to the lower 19 bits of the "permissions" object/column. Each of these represents a single check-box that could be turned on or off (in the most basic UI conceivable):

Bits: 18-16 "Admins" * 18: Soft link * 17: hard link * 16: modify ("edit")

Bits: 15-12 "Group owners" * 15: modify ("edit") * 14: unused, unless it makes sense to restrict "read" for an owner. * 13: soft link * 12: hard link

Bits: 11-8 "object owner" * 11: modify ("edit") * 10: read (as is now) * 9: soft link ("write" currently) * 8: hard link

Bits: 7-4 "group members" * 7: modify ("edit") * 6: read (as is now) * 5: soft link ("write" currently) * 4: hard link

Bits: 3-0 "world" * 3: modify ("edit") -- possibly never used? * 2: read * 1: soft link * 0: hard link

Here, "soft link" would mean attaching easily deletable things like rendering defs, thumbnails, and possibly annotations to an object. This might also be thought of as the "CREATE" flag, i.e. if this flag isn't set, then a world member wouldn't be able to create anything in the given group. "Hard link" means linking images into datasets and the like, i.e. really "using" the data. If "soft link", "hard link" and "modify" are all turned off for everyone, then a group is more or less preserved, i.e. no changes can happen. The only thing to keep in mind would be that group owners and admins will always be able to change the permissions on the group, both loosening and tightening the security, though tightening the security will always require checking all data for validity. But to truly being able to use these groups will rely on also being able to more simply modify the permissions [#2874]

Opinions welcome. ~J.

[#2183] [#2874]

P.S. For anyone that cares, we might be able to encode some of this more compactly, a la:

R--- = r- (0100) = 0 bits of write RW-- = rw (0110) = 1 bit of write RWL- = rl (0101) = 2 bits of write RWLE = re (0111) = 3 bits of write

Where W is the current client interpretation of write, i.e. "soft link", L is hard-linking, and E is editing or modifying.

Current proposal (Mar. 12)

Discussing the complexity of the March 5th email, we came up with the current proposal, which would work something like 2 sliders with an extra checkbox:

Read states

  1. Private: only owner and admins (system+PIs) can read.
  2. Read-only collaborative: members of the group can read.
  3. World-readable: any user can read.

There is no real change in how these function, just that world-readable would need to be supported. For servers with an anonymous user, it would be possible for external users to view data as well.

Write states

  1. No one can edit.
  2. Only owner.
  3. Collaborative Read-only: Group-members can only link rendering settings/thumbnails
  4. Collaborative Read-link: Group-members can link annotations.
  5. Collaborative Read-edit: Group-memebrs can fully link, edit, delete, all group data
  6. World Read-link: as above but for non-group members (unclear if needed in 4.4.0)
  7. World Read-edit: as above but for non-group members (unclear if needed in 4.4.0)

Admin write override

A further requirement is that to protect admins (system/PIs) against accidentally modifying data that has been "published" or otherwise locked, it should be possible to say that admins, who currently can edit anything anytime, cannot override the "no edit" flag without first changing the permissions of the group itself.

In other words, with this flag enabled, the workflow might go: * admin tries to edit a locked item * admin reviews a security warning * admin changes group from read-only to read-edit (Note: this also allows other to edit for this period of time) * admin changes group back.

Misc. Usability

All objects will be modified on read to contain the permissions for that object based on the current user. I.e. if an administrator loads an object the methods "canLink" and "canEdit" will provide true if the admin can take these actions, not if the regular user can.


Document Actions