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.
On Sat, Jan 18, 2014 at 9:37 PM, <neil.burd...@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
> Thanks for any help
> 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.ba...@gmail.com]
> *Sent:* Saturday, January 18, 2014 12:34 AM
> *To:* Burdett, Neil (CCI, Herston - RBWH)
> *Cc:* charles.girar...@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.
> On Fri, Jan 17, 2014 at 6:12 AM, <neil.burd...@csiro.au> wrote:
>> Hi Charles,
>> not a problem. In my previous post I specified the command
>> /home/galaxy/milxcloud/scripts/api/display.py <api_key>
>> 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?
>> From: Charles Girardot [charles.girar...@embl.de]
>> Sent: Friday, January 17, 2014 6:31 PM
>> To: Burdett, Neil (CCI, Herston - RBWH)
>> Cc: email@example.com
>> 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
>> On 17 Jan 2014, at 07:35, <neil.burd...@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>
>> > unless you are stated as as admin user in the "universe_wsgi.ini"
>> > i.e.
>> > admin_users = t...@test.com,te...@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:
>> To search Galaxy mailing lists use the unified search at:
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:
To search Galaxy mailing lists use the unified search at: