Sharing histories in galaxy [long]
Hello, I've recently upgrade to the latest version, and after Greg and Ross explained the security model (in small words, so I'll understand), I played a bit with the new model. I have some usability issue with the new way sharing histories work. It might be because we are relatively a small and tight user base, and the model was designed to work with disperse teams from around them world, where security must be enforced by an appointed security administrator. We don't have security administrator. We need galaxy to be secured, but without the hassle of administration - and everything should 'just work'. The following describe four issues (the description is exaggerated on purpose, please take no offense) Regards, gordon. 1) Steps needed to share histories ---------------------------------- Usage scenario: User A wants to share datasets with User B. 'Old way' (with public datasets, no security): 1. Login as User A. 2. Select History. 3. Click "options" 4. Click "share this history" 5. Enter email of user B 6. Click "Share". Outcome: user B has the new history in his histories list, and can view all files. 'New way' (still with public datasets, no security): 1. Login as User A. 2. Select History. 3. Click "Options" 4. click "share" 5. Enter email of user B. 6. click "share" Outcome: user B doesn't have the history in his histories list. What User B needs to do: 1. click "options" 2. 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). 3. Find the needed shared history, no dates or options to sort by. 4. 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?). 5. click 'clone'. 6. 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? 7. 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 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.
The first option is "make datasets public". This is bad option for two reasons: 1. 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. 2. 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. 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 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). 2) Deleting shared history -------------------------- Scenario: User A wants to delete the current history. the history happens to be shared. 1. Click "options" 2. Click "delete current history" 3. Message box appears: "Are you sure?". click yes. 4. Red warning appears: "History has been shared, unshare it before deleting it". 1. There's no link to 'unshare' it, how do I do that? There's no "unshare" button anywhere. You have to go the the list of histories, find the history in the list, click on the "shared" link, then "unshare" it. quite unintuitive... 2. If I shared the history with twenty users, I need to click the little triangle button and then the "unshare" link for each of them. quite annoying. Why not have an "unshare all" button ? 3. There's no confirmation needed to unshare a history, no user intervention. So theoretically, there's no reason that a "delete" operation would not automatically unshare all shares, then delete the history. 5. This is the real confusing part: To me, "share" means: "allow other users to view the files in this history", and "unshare" means: "don't allow other users to view the files in the history". But in the new galaxy model, "share" means: allow other users to clone the history and then view my files", and "unshare" means: "don't allow other users to clone (or clone again) the history". The old galaxy had no concept of "unshare" - and that's logical - once you shared your files - you can't take them away. In the new Galaxy, "unshare" is not really unsharing: if another user has cloned the shared history, he still has access to your files (de-facto: they are still shared). the other user simply can't clone your history again. -------- 3) Side Effect of Ad-Hoc sharing roles --------------------------------------- Here are the exact steps I made, and two problems that happen with them. ## ## Creating base configuration ## $ hg clone http://www.bx.psu.edu/hg/galaxy galaxy1 $ cd galaxy1 # (my default is python 2.6, too bad for me) $ sed -i 's/^python /python2.5 /' run.sh $ sed -i 's/^python /python2.5 /' setup.sh $ sh setup.sh $ sh run.sh --- In galaxy # # First user # User -> Register username: gordon1@cshl.edu User -> Preferences -> Change Default Permissions for new histories Roles Associated: [Added 'gordon1@cshl.edu'] (click 'save') User -> Logout # # Second User # User -> Register username: gordon2@cshl.edu User -> Preferences -> Change Default Permissions for new histories Roles Associated: [Added 'gordon2@cshl.edu'] (click 'save') User -> Logout # # Third User # User -> Register username: gordon3@cshl.edu User -> Preferences -> Change Default Permissions for new histories Roles Associated: [Added 'gordon3@cshl.edu'] (click 'save') User -> Logout ------------------- This is the base configuration. The following test cases start from this configuration. ------------------- User->Login username: gordon1@cshl.edu # History 1 Options -> delete current history (because of subtle permission issue, see item 4, below) Rename History: "His 1 of Gordon1" Get Data->Upload File: (pasted text: "Data 1 of His 1 of Gordon 1") Rename Dataset to "Data 1 of His 1 of Gordon 1" Options -> Share Current History Username: 'gordon2@cshl.edu' (click 'submit') Permissions dialog: How would you like to proceed? - "Make datasets private to me and the users ..." (option 2) (click 'go') # Note: the second file is uploaded AFTER the share. Get Data->Upload File: (pasted text: "Data 2 of His 1 of Gordon 1") Rename Dataset to "Data 2 of His 1 of Gordon 1" User -> Logout # # New as the second user # User->Login username: gordon2@cshl.edu Options->List Shared histories (the 'other' list link) (seeing two histories shared from gordon1) On "His1", click the little triangle button, then 'clone'. Select "clone all history items" (option 1), click "clone" Options -> List (two histories, 1 unnamed, and one cloned). Switch to the cloned history. # # Problem 1: # In the second user's history pane: The first dataset is OK, the second one is blocked. Technically this is correct, because the second dataset was created after the share, and the new ad-hoc role was not applied to it. but from a usability POV, this is confusing - the history was cloned by the second user AFTER the first user created the files. In real life: 1. User A shares a History with User B. 2. User A adds more files to the history 3. User A tells user B: "I've added more files, clone the history again" 4. User B clones the history (with the new items), but the new items are blocked. In the 'previous' version of galaxy (before the changeset that introduced the share mechanism), the "share" action literally meant "Copy the current content of the this history to other users" - and you could do it multiple times, with different contents of the same history. This is not the case anymore. Also, going back to the first user (gordon1) and re-sharing the history doesn't work (a red warning appears that this history is already shared). A non-technical user (who doesn't care about roles/groups/permissions and just wants things to work) will be very frustrated. The technical solution of visiting every dataset and adding the role is maybe good for one or two datasets, but not to twelve datasets that were created by a workflow. # # Problem 2 : # (this might be a bug) # continuing from the previously described state User -> Logout User -> Login, username: gordon1@cshl.edu (first user) Options -> List Histories Switch to "His 1 of Gordon1" This history contains two datasets: Dataset 1 ( "Data 1 of His 1 Of Gordon 1" ) has: [access] roles associated: "Sharing role for: gordon1@cshl.edu, gordon2@cshl.edu" roles not associated: "gordon1@cshl.edu" Dataset 2 ( "Data 2 of his 1 of gordon 1") has: [access] roles associated: "gordon1@cshl.edu" roles not associated: "sharing role for: gordon1@cshl.edu, gordon2@cshl.edu". Options -> Share username: gordon3@cshl.edu (third user) (click 'submit') Permissions dialog: How would you like to proceed? - "Make datasets private to me and the users ..." (option 2) (click 'go') The roles of all the datasets is reset to 'sharing role for: gordon1@cshl.edu, gordon3@cshl.edu" Meaning that the second user (gordon2), which was previously allowed to view at least one dataset, is now deprived of even this privilege. Even if this is technically correct, from a usability POV it is very confusing. What the first user did: 1. share history with second user (implied: I want the second user to view my files). 2. share history with third user (implied: I want the third user to also view my files). But the outcome is that the second user is now blocked. 4) Subtle security bug/feature: ------------------------------- The first time a NEW user logs on, an empty history is created. Going to USER->Preferences->Change default permissions Does not change the permissions of current history, and there's no button to create a new history (because this is an empty history). So the files in the current history will be public. While technically correct, this behavior is confusing. What the user wants is: "everything I create from now on has X permissions", But what technically is done is: "New histories will have X permissions, but you are currently in an old history which uses the old settings". --------------------------- Thanks for reading so far.
Hello Assaf, Thanks very much for all of your feedback on the new approach to sharing histories. I'll incorporate some of your ideas that will improve this feature as soon as possible. Your insight is much appreciated! Greg Von Kuster Galaxy Development Team Assaf Gordon wrote:
Hello,
I've recently upgrade to the latest version, and after Greg and Ross explained the security model (in small words, so I'll understand), I played a bit with the new model. I have some usability issue with the new way sharing histories work.
It might be because we are relatively a small and tight user base, and the model was designed to work with disperse teams from around them world, where security must be enforced by an appointed security administrator. We don't have security administrator. We need galaxy to be secured, but without the hassle of administration - and everything should 'just work'.
The following describe four issues (the description is exaggerated on purpose, please take no offense)
Regards, gordon.
1) Steps needed to share histories ----------------------------------
Usage scenario: User A wants to share datasets with User B.
'Old way' (with public datasets, no security):
1. Login as User A. 2. Select History. 3. Click "options" 4. Click "share this history" 5. Enter email of user B 6. Click "Share".
Outcome: user B has the new history in his histories list, and can view all files.
'New way' (still with public datasets, no security): 1. Login as User A. 2. Select History. 3. Click "Options" 4. click "share" 5. Enter email of user B. 6. click "share"
Outcome: user B doesn't have the history in his histories list.
What User B needs to do: 1. click "options" 2. 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). 3. Find the needed shared history, no dates or options to sort by. 4. 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?). 5. click 'clone'. 6. 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? 7. 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 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.
The first option is "make datasets public". This is bad option for two reasons: 1. 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. 2. 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. 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 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).
2) Deleting shared history -------------------------- Scenario: User A wants to delete the current history. the history happens to be shared.
1. Click "options" 2. Click "delete current history" 3. Message box appears: "Are you sure?". click yes. 4. Red warning appears: "History has been shared, unshare it before deleting it". 1. There's no link to 'unshare' it, how do I do that? There's no "unshare" button anywhere. You have to go the the list of histories, find the history in the list, click on the "shared" link, then "unshare" it. quite unintuitive...
2. If I shared the history with twenty users, I need to click the little triangle button and then the "unshare" link for each of them. quite annoying. Why not have an "unshare all" button ?
3. There's no confirmation needed to unshare a history, no user intervention. So theoretically, there's no reason that a "delete" operation would not automatically unshare all shares, then delete the history.
5. This is the real confusing part: To me, "share" means: "allow other users to view the files in this history", and "unshare" means: "don't allow other users to view the files in the history".
But in the new galaxy model, "share" means: allow other users to clone the history and then view my files", and "unshare" means: "don't allow other users to clone (or clone again) the history".
The old galaxy had no concept of "unshare" - and that's logical - once you shared your files - you can't take them away.
In the new Galaxy, "unshare" is not really unsharing: if another user has cloned the shared history, he still has access to your files (de-facto: they are still shared). the other user simply can't clone your history again. --------
3) Side Effect of Ad-Hoc sharing roles --------------------------------------- Here are the exact steps I made, and two problems that happen with them.
## ## Creating base configuration ## $ hg clone http://www.bx.psu.edu/hg/galaxy galaxy1 $ cd galaxy1 # (my default is python 2.6, too bad for me) $ sed -i 's/^python /python2.5 /' run.sh $ sed -i 's/^python /python2.5 /' setup.sh $ sh setup.sh $ sh run.sh --- In galaxy
# # First user # User -> Register username: gordon1@cshl.edu
User -> Preferences -> Change Default Permissions for new histories Roles Associated: [Added 'gordon1@cshl.edu'] (click 'save')
User -> Logout
# # Second User # User -> Register username: gordon2@cshl.edu
User -> Preferences -> Change Default Permissions for new histories Roles Associated: [Added 'gordon2@cshl.edu'] (click 'save')
User -> Logout
# # Third User # User -> Register username: gordon3@cshl.edu
User -> Preferences -> Change Default Permissions for new histories Roles Associated: [Added 'gordon3@cshl.edu'] (click 'save')
User -> Logout
------------------- This is the base configuration. The following test cases start from this configuration. -------------------
User->Login username: gordon1@cshl.edu
# History 1 Options -> delete current history (because of subtle permission issue, see item 4, below) Rename History: "His 1 of Gordon1" Get Data->Upload File: (pasted text: "Data 1 of His 1 of Gordon 1") Rename Dataset to "Data 1 of His 1 of Gordon 1" Options -> Share Current History Username: 'gordon2@cshl.edu' (click 'submit') Permissions dialog: How would you like to proceed? - "Make datasets private to me and the users ..." (option 2) (click 'go')
# Note: the second file is uploaded AFTER the share. Get Data->Upload File: (pasted text: "Data 2 of His 1 of Gordon 1") Rename Dataset to "Data 2 of His 1 of Gordon 1"
User -> Logout
# # New as the second user # User->Login username: gordon2@cshl.edu Options->List Shared histories (the 'other' list link) (seeing two histories shared from gordon1) On "His1", click the little triangle button, then 'clone'. Select "clone all history items" (option 1), click "clone"
Options -> List (two histories, 1 unnamed, and one cloned). Switch to the cloned history.
# # Problem 1: # In the second user's history pane: The first dataset is OK, the second one is blocked. Technically this is correct, because the second dataset was created after the share, and the new ad-hoc role was not applied to it. but from a usability POV, this is confusing - the history was cloned by the second user AFTER the first user created the files. In real life: 1. User A shares a History with User B. 2. User A adds more files to the history 3. User A tells user B: "I've added more files, clone the history again" 4. User B clones the history (with the new items), but the new items are blocked.
In the 'previous' version of galaxy (before the changeset that introduced the share mechanism), the "share" action literally meant "Copy the current content of the this history to other users" - and you could do it multiple times, with different contents of the same history. This is not the case anymore.
Also, going back to the first user (gordon1) and re-sharing the history doesn't work (a red warning appears that this history is already shared). A non-technical user (who doesn't care about roles/groups/permissions and just wants things to work) will be very frustrated. The technical solution of visiting every dataset and adding the role is maybe good for one or two datasets, but not to twelve datasets that were created by a workflow.
# # Problem 2 : # (this might be a bug) # continuing from the previously described state
User -> Logout
User -> Login, username: gordon1@cshl.edu (first user) Options -> List Histories Switch to "His 1 of Gordon1" This history contains two datasets: Dataset 1 ( "Data 1 of His 1 Of Gordon 1" ) has: [access] roles associated: "Sharing role for: gordon1@cshl.edu, gordon2@cshl.edu" roles not associated: "gordon1@cshl.edu"
Dataset 2 ( "Data 2 of his 1 of gordon 1") has: [access] roles associated: "gordon1@cshl.edu" roles not associated: "sharing role for: gordon1@cshl.edu, gordon2@cshl.edu".
Options -> Share username: gordon3@cshl.edu (third user) (click 'submit') Permissions dialog: How would you like to proceed? - "Make datasets private to me and the users ..." (option 2) (click 'go')
The roles of all the datasets is reset to 'sharing role for: gordon1@cshl.edu, gordon3@cshl.edu" Meaning that the second user (gordon2), which was previously allowed to view at least one dataset, is now deprived of even this privilege.
Even if this is technically correct, from a usability POV it is very confusing. What the first user did: 1. share history with second user (implied: I want the second user to view my files). 2. share history with third user (implied: I want the third user to also view my files).
But the outcome is that the second user is now blocked.
4) Subtle security bug/feature: ------------------------------- The first time a NEW user logs on, an empty history is created. Going to USER->Preferences->Change default permissions Does not change the permissions of current history, and there's no button to create a new history (because this is an empty history).
So the files in the current history will be public.
While technically correct, this behavior is confusing.
What the user wants is: "everything I create from now on has X permissions", But what technically is done is: "New histories will have X permissions, but you are currently in an old history which uses the old settings".
--------------------------- Thanks for reading so far. _______________________________________________ galaxy-dev mailing list galaxy-dev@bx.psu.edu http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev
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:
1) Steps needed to share histories ----------------------------------
Usage scenario: User A wants to share datasets with User B.
'New way' (still with public datasets, no security): 1. Login as User A. 2. Select History. 3. Click "Options" 4. click "share" 5. Enter email of user B. 6. 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: 1. click "options" 2. 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".
3. 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.
4. 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.
5. click 'clone'. 6. 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.
7. 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.
1. 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.
2. 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
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:
1) Steps needed to share histories ----------------------------------
Usage scenario: User A wants to share datasets with User B.
'New way' (still with public datasets, no security): 1. Login as User A. 2. Select History. 3. Click "Options" 4. click "share" 5. Enter email of user B. 6. 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: 1. click "options" 2. 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".
3. 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.
4. 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.
5. click 'clone'. 6. 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.
7. 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.
1. 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.
2. 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
participants (2)
-
Assaf Gordon -
Greg Von Kuster