2008-08-26 Permissions discussion
Attending: Will, Scott, Chris, Brian, Jean-Marie, Josh, Jason
Notes
- Introduction (Ola)
- Filtered by clients
- 'Generally wrong' (Josh)
- Should be filtered at the API level
- server default is world-readable
- how people understand the different groups...
- @terminology of "default" group is bad. "Primary" group?! (J-M)
- clients don't currently allow changing group or umask
- "PI" as scoped admin
- "rwrwr-" is read-with-link
- Purpose of meeting:
- to analyze use cases
- to make decisions for which are dangerous
- also:
- too many options might confuse users
- other clients might create things differently
- difficult to rollback "pandora's box" (cF. IAdmin.unlock)
- Do we really need to have world permission?
- pretty much everyone agrees we take away the world permission
- group permission?
- in unix, ... (brian)
- but we don't have the ability to take permissions away (chris)
- easy to put in client tools to increase visibility (chris)
- Level of flexibility
- "some people in my lab are fine" (will)
- Ola: the shares solution, working on that now
- PIs & groups
- @Can PI's add users to group?
- Group creation sysadmin only? Yes. (Is essentially a loop-hole)
- Hiding data
- Active group v. Primary group. Brian: keep "default" group
- Can get tricky wanting to show things to 2 groups?
- When things get too complicated, you use shares (READ-ONLY)
- Has to have a nice interface (action basket)
- Data creation
- Part of login process you can select your group.
- Don't bother the user if there's not more than one.
- "Change active group"
- The first time ever you don't the groups you are a member of
- 2 stage login.
- @Guarantee we can change the group in a session
- @Should PI be able to change default group?
- Will: 2 Pis have me, can I decide my default group? Yes.
- Don't ask permissions on every login
- but more obvious in import
- but don't currently use scopes
- Drop-down: "which group should get read/write permissions?" "world?"
- @Warning if people are putting things into another group's project
- Josh: in terms of style, can we treat this like "View all files" drop down?
- Would require new group or world-group? Josh: server does filtering already
- multi-group collaboration requires everything to be put in as group/world readable
- Jason: 2 users in lab (SWEDLOW), E. does own
- E. is in another group (MBL), multi-site, world-wide experimenter
- E. knows whether to import as MBL or SWEDLOW
- 2 questions
- E. imports data into wrong group? chown is ok, the cuts are difficult
- "If you punish them hard enough they won't do it again" (Will)
- @Buy some speakers
- 4 groups. The image can only be assigned to one group.
- E. must make the decision
- The trick is that it's simple for the user, but the preparation has to be right
- Users & PIs have had to create a new group with X users, etc.
- Significant preparation overhead, cognizant of what you're doing
- Groups of groups? No modern permissions system does this (Chris) Windows (Brian)
- Jason: Would like to move Will to "oldlab" group, and the PI is.
- Josh: Potentially very difficult.
- Jean-Marie: active flag? Josh: Yes, that exists. @Show "old members"
- Jason: Just give 'em a new account. (@Add to faq)
- Or she's in two groups and she has to make a decision about active group.
- Default group
- @First new group creation should delete default group
- @Each user creation should ask to remove default group
- Renaming is easier than deleting
- How do we start?
- root logins, creates group1, create users ... ?
- Just put up good documentation
- No system makes it completely easy
- Example
- E. correctly imported to new dataset1 (SWEDLOW)
- People want to copy (?)
- Want to link our data into a second dataset2 (MBL)
- Clients need to pop up box:
- "This will not be visible, would you like to create share"
- @Should the server throw an exception if you try to make bad link? (flag in umask)
- It's not possible to have 2 groups with access to one image?
- Draw lines: these are things you can and can't do.
- Ola: How to we explain to users? They don't know.
- Different datasets have different properties (color, ...)
- When viewing my file-tree I can see the incapacity
- @ "No collaborating between two groups" (docs)
- "Omero allows to collaborate only in group not across them". To cross the boundary, do shares.
- Scope the view on the group, or show both with different color?
- Chris: E. wants to see data in MBL group that applies to SWEDLOW
- We can't dictate what a user wants to see.
- Realistically, none of this will happen (Jason)
- GPDI hierarchy.
- @Server-side safety net
- Multi-server clients? Not for a while. (SGPDI hierarchy!)
- @Someone should sit down with a user who currently needs to drag between groups
- Data analysis people get annoyed/depressed if they see bad data
- Private->public after review.
- Psychological effects of moving/revealing data
- Need
- Whole list of strategies (ways to make life easier)
- Guide people with these tasks
- They will learn (with the pop up about shares)
- Better than Chris going in and changing permissions repeatedly
- Conditions where GPDI is what I want. User interface is a choice.
- My data (default)
- GPDI Ignore users (whole group)
- UPDI Pick individual users (as now)
- GUPDI (Nightmare?)
- Ola: I would like to see every image in dataset, regardless
- How should they be distinguished? (Regardless of ownership)
- Jason: malformed and opposite importing data into someone else's dataset
- Ola: I'm PI, I would like to import into a dataset
- Jason: we never do that.
- Brian: no conditions?
- Chris: whole concept of collaboration falls apart.
- Defaults
- Should be sticky. Change in WebAdmin, changes in Insight
- No group defaults.
- Josh leaves early. (no more notes)