Greg,
You rock. Thanks for taking my ramblings seriously.
On the public/private issue we'll simply agree to disagree... For now I'll use a simplified security model (based on the patch I sent some time ago), and in the future I'll see if it holds.
Thanks again, gordon.
Greg Von Kuster wrote:
Hello Assaf,
Here are some comments on the first portion of your original message. I'll respond to the remaining parts of your original message in separate emails. The following comments refer to changes made in change set 2556.
Assaf Gordon wrote:
- Steps needed to share histories
Usage scenario: User A wants to share datasets with User B.
'New way' (still with public datasets, no security):
- Login as User A.
- Select History.
- Click "Options"
- click "share"
- Enter email of user B.
- click "share"
Outcome: user B doesn't have the history in his histories list.
This is true, but now user B has a link to a history which he can clone 1 or more times as long as sharing link remains.
What User B needs to do:
- click "options"
- click the *other* list link (there are two of them, both named
'link', and one has to actually read the rest of the sentence to know what's the different between them).
The first 'list' is now "Previously stored histories" and the 2nd 'list' is now "Histories shared with you by others".
- Find the needed shared history, no dates or options to sort by.
The list of "histories shared with you by others" is now a "grid" layout which displays the following for all shared histories: history name, number of datasets ( for each state ), date created, last updated date, shared by ( user email ). You can sort by most of these columns.
- click on the tiny triangle button, which will show a pop-up menu
with only one button 'clone' (which he's going to click anyway, so why not make it available as a huge button on the main page?).
There are buttons on the grid layout that allow you to either clone a selected history or unshare it.
- click 'clone'.
- User sees a technical question about cloning deleted items. there's
no default selection, so you can't just click "clone". you have to read and understand what's going on. Don't underestimate the annoyance of this: You advertise galaxy as easy to use for biologists, who don't need to understand the technical aspects - so why make them read technical details and choose these options?
This technical question has been eliminated, and only the active ( undeleted ) datasets are copied in the cloned history.
- Only then, the shared+cloned history appears in the history list.
With security model in place (meaning datasets are not public), things get more confusing. User A wants to share history with user B. User A's implied wish: "I want User B to view my files". When User A clicks "share", enters the email and click "share", he is then presented with four permission related options.
The last one is "Don't Share". This is kind of funny. it reminds me of clicking the "start" button to shutdown the computer in you-know-which operating system. The scenario of selecting "Don't Share" and clicking "Go" button - this is a no-op. why is it needed ? If this wasn't a web-application - then yes, this modal dialog would require a 'cancel' button. But this is a web-application. just click on another link instead of clicking "go". A "go" button implies something will be done.
The "Don't share" option has been eliminated.
The second-to-last is "Share Anyway (don't change any permission)". This is a problem waiting to happen - you are explicitly allowing the user to do something that you know will not work.
From a technical perspective, that's OK - a knowledgeable user can later on manually set permissions, or can later on whine to the administrator about permission problems (or my favorite: User A tells User B to ask the admin to give him permissions).
IMHO, a program should not allow a user to do anything that will definitely not work.
Actually, this option generally will work. The only time that it will not work is if there are no histories being shared that include datasets that require no permissions changes. I've added a check to ensure that at least 1 history includes at least 1 dataset on which permissions do not need to be changed, and if there is not a history that falls into this category, this option is not displayed.
The first option is "make datasets public". This is bad option for two reasons:
Hmm, I disagree with this issue. There are times when a user may have restricted datasets that he now wants to make public.
- User A don't want to make his datasets public (otherwise he would
not set permissions on them). All he wants is to allow User B to view his files.
If he only wants user B to view his file, he has that option available to him.
- If permissions problem persist, Users will get accustomed to just
'make everything public' because that's the easy solution. and this will make the whole security thing redundant.
I disagree with this issue as well. If a user is familiar enough with setting various permissions on datasets, then he will be able to understand the difference between sharing a dataset with 1 or more other users ( but keeping it restricted from all of the public ), and making it public so anyone can see it.
Also remember that PUBLIC means anybody can view them - anybody, not just people you shared it with. This is not obvious. this means "no security".
The option to make datasets public is fairly obvious in this regard as the option states "Make datasets public so anyone can access them". \
The second option is "make datasets private to me and the user...". This seems like what the user actually wants, but it has strange side effects (see item 3, below).
I'll look into the remaining issues in a separate change set / email response.
Thanks very much for all of you valuable feedback!
Greg Von Kuster Galaxy Development Team