export permissions as a separate flag

[nathandunn]

The current model has the permissions:

• read, export, write, and admin.

Each of these has a rank.

However, "export" would be better suited to be configured as a separate option, since you may only want some curators to export and not others, or you may want folks who can read to export.

The argument would be that this would disuade folks from pre-publishing data accidentally or on purpose.

[nathandunn]

Areas to assess:

• get gff3
• get sequence
• save track
• web services
• sequence panel

[nathandunn]

• [ ] assess permission differences
• [ ] fix permission bug where it always brings back the largest one

[hexylena]

Per comments in #1762, it might be nice to re-think of permissions here as distinct operations that can be granted to roles, rather than as a strictly linearly increasing set of permissions. This would be more appropriate for sites with different trust levels for different activities. I do still see write as a superset of read and not making so much sense without it.

A somewhat exhaustive list of permissions that should be granted to users or groups

Category	Permissions
organism	read (access name / metadata), write (change name/metadata), download (just show the button, obviously doesn't prevent the most determined user), export to chado, create a new organism.
organism-tracks (per track)?	read (access to track data), write (add new tracks)
organism-annotation	read (see existing annotations), write (create or update annotations)
groups	admin (change name / membership / whether or not the member list is private or public) As you can see I think of apollo much more like github than like something I deploy in my lab for 5 people, I want it to be a service where users can self-organise, but maybe this is at odds with the goals of the project. Group names and usernames should be public (for sharing)
users	only site-admins may create users, but ideally users should be able to register. Users may read/write/delete their own metadata (name/email)

Sites should be able to specify (in config) a baseline set of permissions that users are granted upon creation. Sites should also specify in config permissions that users should not be able to grant themselves, e.g. if an admin needs strict control over chado export they could ensure that organism-creation doesn't grant the user the ability to export to chado.

Sharing is incredibly important and currently hard to do (at least in a way which favours users self-organising.) The admin must manage all sharing (or make users admins of organisms, but in the past that carried extra permissions that I did not want to grant)

• user who created an organism should be able to share it with any group or user (since bare minimum the group + user names are public, not the emails obviously). If you're worried how people will react to this you could consider the galaxy model of "must know their email address to share unless the admin makes usernames public" but the UX of that is not great.
• when a user "shares" their organism with another user we should offer them a pre-defined set of permissions or let them decide in detail.
  • example predefined ones would be "admin", "contributor", "viewer"
  • (maybe not necessary to implement?) detailed sharing would let the user control all permissions defined under organism, organism-tracks, and organism-annotation above.

Note that there's no admin permission for organism. I think we could get rid of that concept of one person who can see everything. If this was implemented in conjunction with per-track read permissions this could provide a really nice ucsc-like experience (visualize your own data to public organisms).

(As per normal, just thinking out loud. Not going to have the time to implement this any time soon.)