Galaxy: Access to shared histories

Created on 17 Apr 2018  路  13Comments  路  Source: galaxyproject/galaxy

I want to share a history via link. If I do so, the data items are not viewable. (Permissions on first dataset were manually changed.)

image

The only way to change this is to change the access permissions in my history for every item by hand (!!!). It would be nice if either

  • the default option that if I share my history via link, all items are viewable or
  • that checkboxes with make all items viewable and / or make all items editable are offered.

Thanks for considering.

areUI-UX aresharing help wanted kinbug

All 13 comments

This just happened to me to. Super mind numbing to to edit dataset permissions individually. Sharing by link should definitely give a checkbox to remove any access permissions.

Update: there is also no API for this so it isn't possible to automate with bioblend.

This happened again to us and it's really tough to explain to our users: "No sharing doesn't work like all of the other systems, that 'NOTE' in the management screen for access permissions is the most important note and you need to read + understand it to do sharing right." It isn't a user problem, it's a user experience/expectations problem from the other web based systems they use. I think there is sufficient evidence that our sharing interface is "clunky" and would like to propose the following (requiring API + UI changes):

I'd like to propose we try and align our interface (where possible) like Google Drive to better match what users will be familiar with. A history is like a folder, and then inside there are datasets. Honestly I think we should copy the dialog wholesale:

history-sharing

And then re-use exactly the same sharing form for dataset permissions, just like gdrive does for sharing folders vs datasets. If necessary, put in a "Old sharing form" button at the bottom which shows the old sharing form?

Problem continues with creating pages. From @eschen42 on gitter

If I create and make "accessible" Galaxy pages that reference particular datasets (through the page editor, not by pasting links), will this make them not public?

@dannon @guerler what do you think about this? (Easy) sharing is for our users currently broken :(

This isn't something we recently broke, right, it has always been like this?

(regardless of the answer to that, yes, we should improve the behavior here somehow -- sharing by a link being worthless is pretty annoying)

I'd imagine that this is how it always worked, but we should add some smart logic to the sharing functions to detect permission issues and then an easy and immediate way for the user to change them.

Clippy pops up: "hey, it looks like you are trying to share this item with x, but they won't be able to view yz due to permissions, would you like to give them access to all these items, some of these items, or none?" Similarly for making sharable links, allow making things public.

@blankenberg Ok, cool, I thought it had always been like this, too. I like that solution, should be fairly straightforward to detect and have an extra action on the sharing interface.

As an aside, it looks like permissions don't exist at the collection level since it can be viewed/expanded; perhaps they should be?

Could also just be looking at the image wrong.

Yes this is how it always worked.

  • sharing a link
  • sharing pages
  • sharing histories

are all affected by this.

I mean, +0 on clippy since I definitely proposed that in https://github.com/galaxyproject/galaxy/issues/935 , but I'd really rather it be fixed with a google style sharing dialog and a checkbox (defaulting to checked) that says "all of these items will be shared with the people you're allowing access" (since that would be less complicated/overwhelming on the UI side than allowing complicated operations like selecting individual datasets.)

I was halfway there with https://github.com/galaxyproject/galaxy/pull/1334, I don't think much is missing there

I had a rudimentary attempt, that probably needs quite a bit more work

As an aside, it looks like permissions don't exist at the collection level since it can be viewed/expanded; perhaps they should be?

Could also just be looking at the image wrong.

If so, I see it the same way. I have collections with 211 members each that have been multiply processed (i.e., processed with tools that produce multiple 211-member collections) - to manipulate each dataset's permission manually is daunting to say the least.

This should be fixed with #6793 @joachimwolff we'll upgrade tuesday.

Was this page helpful?
0 / 5 - 0 ratings