Hey Neil,

While poking through a few options for you, I remembered we added 'expose_dataset_path' to universe_wsgi.ini.  If you're comfortable with users knowing full pathnames, you can enable this 'expose_dataset_path = True' and everyone will be able to see their full paths.

-Dannon


On Sat, Jan 18, 2014 at 9:37 PM, <Neil.Burdett@csiro.au> wrote:
Thanks Dannon,
                      Apologies for the length of the email, I'll try and be as succint as possible.

I am using Galaxy as a tool for medical image processing. We have a number of organisations (researchers and clinicians ) who would like to use the medical imaging tools we have developed, so are using Galaxy to make them available to the whole community. The researchers and clinicians would just prefer to select a file press execute and then everything would be done i.e. uploaded, processed, results returned.

I've managed to achieve this (using a test account which is an admin user). In summary, using John Chilton's "multi-file" branch of Galaxy, the user can select multiple files and then presses execute. The code(and workflows) then upload all the files selected, splits them into smaller datasets (as the tool only needs 2 input files - for example the user may upload 0179_AV45.hdr, 0179_AV45.img, 0279_AV45.hdr, 0179_AV45.img, 0199_AV45.hdr and 0199_AV45.img, given these 6 input files; 3 datasets will be created based on the filenames i.e. 0199_AV45.hdr and 0199_AV45.img will be in one dataset etc). Another tool is responsible for batching and executing the medical imaging tool with each of these 3 datasets, and finally all the results are returned and then emailed back to the user ( so no user interaction is required other than selecting files and pressing execute)

This all worked fine as an admin user, but as a non admin user we are unable to get the file_name from the /api/histories/contents/ etc... being upload for the dataset_id.dat. We need to get the history id of that datase_id.dat filename so we can execute the workflow. 

As admin, I have a script that is able to get get all the files uploaded (under/histories/contents/etc ...) and then examine each history id to get the "file_name" and match it with the name that we just uploaded. From this we could then get the history_id. But seen as we can't get hold of the file_name unless your an admin user. Do you know how we can get hold of the history_id of the filename i.e. we can't just assume it's the last entry in /history/contents. So given only a database_'id'.dat filename how can I get the history id dynamically with no user interaction and not being an admin user?

Thanks for any help
Neil

p.s. do you know where in the code it stops file_name from being displayed (using the scripts/api/display.py script)
From: Dannon Baker [dannon.baker@gmail.com]
Sent: Saturday, January 18, 2014 12:34 AM

To: Burdett, Neil (CCI, Herston - RBWH)
Cc: charles.girardot@embl.de; Galaxy Dev

Subject: Re: [galaxy-dev] Can't view file_name in histories via API unless admin?

Hi Niel,

Galaxy does not expose filepaths to non-admin users intentionally.  For executing a workflow with that particular script, the 'file_id' in question in that example should be an hda, which is what api/history/contents will display for your users as the 'id' for each history item.

-Dannon


On Fri, Jan 17, 2014 at 6:12 AM, <Neil.Burdett@csiro.au> wrote:
Hi Charles,
               not a problem. In my previous post I specified the command line:
The <api_key> in your question refers to the api_key of an "admin" user, however, the history_id (ebfb8f50c6abde6d) refers to a history not "owned" by the admin user using the unique api_key i.e. another user, hence the error message

I hope that answers your question?

Neil

________________________________________
From: Charles Girardot [charles.girardot@embl.de]
Sent: Friday, January 17, 2014 6:31 PM
To: Burdett, Neil (CCI, Herston - RBWH)
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] Can't view file_name in histories via API unless admin?

Hi Neil,

sorry, this is not an answer to your post, I hope you won t mind me stepping in your thread this way.
Your message kept my attention because of your note: I am surprised by the error message you report when trying to use an admin API key.

How does galaxy know the user who is making the call?

Sorry if I am missing the obvious

bw

Charles

On 17 Jan 2014, at 07:35, <Neil.Burdett@csiro.au> wrote:

> Hi,
>     it seems that the entry "file_name:" does not appear when running the command
>
> /home/galaxy/milxcloud/scripts/api/display.py <api_key> http://barium-rbh:9100/extras/api/histories/ebfb8f50c6abde6d/contents/4a56addbcc836c23
>
> unless you are stated as as admin user in the "universe_wsgi.ini"
> i.e.
> admin_users = test@test.com,test1@test.com
>
> is this known?
>
> Is there anyway to get around this as we don't want all users to be admin, however, they need access to this field.
>
> Note that you can't use an admin's <api_key> as you'll get the error
> "Error in history API at listing dataset: History is not owned by the current user"
>
> Thanks
> Neil
> ___________________________________________________________
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>  http://lists.bx.psu.edu/
>
> To search Galaxy mailing lists use the unified search at:
>  http://galaxyproject.org/search/mailinglists/


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/