On Aug 15, 2012, at 10:08 AM, Sascha Kastens wrote:
Hi again! I was able to implement a quite dirty solution:
first I edited /lib/galaxy/model/mapping.py and extended
assign_mapper( context, User, User.table, properties=dict( histories=relation( History, backref="user", order_by=desc(History.table.c.update_time) ), active_histories=relation( History, primaryjoin=( ( History.table.c.user_id == User.table.c.id ) & ( not_( History.table.c.deleted ) ) ), order_by=desc( History.table.c.update_time ) ), galaxy_sessions=relation( GalaxySession, order_by=desc( GalaxySession.table.c.update_time ) ), stored_workflow_menu_entries=relation( StoredWorkflowMenuEntry, backref="user", cascade="all, delete-orphan", collection_class=ordering_list( ’order_index’ ) ), _preferences=relation( UserPreference, backref="user", collection_class=attribute_mapped_collection(’name’)), # addresses=relation( UserAddress, # primaryjoin=( User.table.c.id == UserAddress.table.c.user_id ) ) values=relation( FormValues, primaryjoin=( User.table.c.form_values_id == FormValues.table.c.id ) ), api_keys=relation( APIKeys, backref="user", order_by=desc( APIKeys.table.c.create_time ) ), ) )
by this: currentHistory=relation( History, primaryjoin=( ( History.table.c.user_id == User.table.c.id ) & ( not_( History.table.c.deleted ) ) & (GalaxySession.table.c.current_history_id == History.table.c.id) ), order_by=desc( GalaxySession.table.c.update_time ) )
As far as I am correct, this selects all current histories of all sessions per user. These histories get sorted by the latest session change which should always lead to the current history as the first entry.
Inside my tool I use this to get the current history id and hash it to an id which can be used for API calls:
${__app__.security.encode_id( ’%s’ % $__app__.model.User.get($__user_id__).currentHistory[0].id )}
Until now everything seems to work as it should.
Hi Sascha, This will break down if you have a user with more than one active sessions (in two browsers, for example). The most recent session and its current history will always be used, rather than the one that the job was initiated from. Jobs are intentionally decoupled from histories since histories are not the only context in which a job can run. There may be accurate ways of getting to the parent history at the job context, but it'd help to know what you're trying to do. Thanks, --nate
Finally I have another question about the histories and API. Referring to this thread: http://gmod.827538.n3.nabble.com/How-to-use-scripts-api-update-py-td3657803....
Are you working on this? Updating history items via the API would be really helpful for my usecase. If not, can you give me some hints where I can have a look at to enable it by my own?
No, nothing's been written for this yet. Have a look at lib/galaxy/web/api/history_contents.py, and you may find the update() method in other API controllers to be a useful template. One that is fairly well sorted is the quota API (quotas.py). --nate
Thanks a lot!
Cheers, Sascha
Original Message processed by CONSOLIDATE Subject: [galaxy-dev] Some questions about histories Sent: Dienstag, 14. August 2012 12:10 From: Sascha Kastens (s.kastens@gatc-biotech.com) Hi all!
I have two questions about histories in Galaxy:
1. Is it possible to mark/set a history as published via the API? 2. How can I get the ID of the current users history via a tool? Something like ${__app__.model.User.get($__user_id__).histories[0].id} ?!
Thanks in advance!
Cheers, Sascha ___________________________________________________________ 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: