Hi, Carrie

Can you (or the other user) open the javascript console and try to load the
history again in order to reproduce the problem?

You can open the console:
- by going to the menu command: Tools->Web Developer->Web Console in
Firefox.
- going to: the 'control menu' (the three horizontal bar button on the top
right)->Tools->Javascript Console in Chrome.
- by enabling the developer tools and going to Develop->Show Error Console
in Safari. Enable the developer menu by going to
preferences->advanced->Show develop menu in menu bar.

It may be there's an error on the client side involved and having this open
will show that error. Additionally, if an API call is returning a 400 range
http error - you won't see it in the server logs.

Thanks for the help and let me know what you find,
Carl



On Wed, Mar 12, 2014 at 10:22 AM, Ganote, Carrie L <cgan...@iu.edu> wrote:

> Hi Hans,
>
> Thanks for the advice! Sadly, I think our situations might not be the
> same. We've been using external auth for a long time, so it's definitely
> not a new change, and the user in question created their account after this
> was in place. We log our users in with just their IU username, and tack the
> "@indiana.edu" onto it with Apache to create the email address after
> authenticating the username through IU. I checked the galaxy_user table,
> and there doesn't seem to be any accidental duplicates or funny business
> with the user name.
>
> User is active, external, not deleted, not purged, and we don't enforce
> any disk quotas.
>
> I pulled the histories associated with the user id:
> select * from history where user_id = '95' ;
>   id  |        create_time         |        update_time         | user_id
> |        name        | hid_counter | deleted | purged | genome_build |
> importable | slug | published | importing
>
> ------+----------------------------+----------------------------+---------+--------------------+-------------+---------+--------+--------------+------------+------+-----------+-----------
>  1665 | 2014-02-23 18:42:23.497483 | 2014-03-11 19:04:55.614609 |      95
> | Unnamed history    |           5 | t       | f      | dm3          | f
>        |      | f         | f
>  1722 | 2014-02-28 20:46:50.292015 | 2014-03-11 19:06:47.498152 |      95
> |                 RNAseq |           7 | f       | f      | ?            |
> f          |      | f         | f
>  1811 | 2014-03-11 19:04:55.910381 | 2014-03-11 19:13:06.82213  |      95
> | Unnamed history    |           2 | f       | f      | ?            | f
>        |      | f         | f
> (3 rows)
>
> I took a look at "RNAseq":
> select * from history_dataset_association where history_id = '1722';
> id: 10027
> history_id: 1722
> dataset_id: 7258
> create_time: 2014-02-28 20:51:32.369667
> update_time: 2014-03-06 15:37:27.033951
> copied_from_history_dataset_association_id: 9778
> hid: 4
> name :
> https://usegalaxy.org/datasets/bbd44e69cb8906b52e29eb7a7c6c4900/display?to_ext=
> peek:@HWI-B5-690_0086_FC:2:1:2711:936#CNNNNN/1  ... (this checks out with
> the datafile)
> extension: txt
> metadata: {"data_lines": 145087556, "dbkey": "dm3"}
> deleted: f
> visible: t
> purged: f
> extended_metadata_id: uploaded txt file
>
> I found this file in the dataset_files and there doesn't appear to be
> anything wrong about it. It appears that the datasets in question were
> downloaded from Galaxy main (by the looks of the upload URL).
>
> I'm at a loss. I'll ask the user to clear all their browser information
> just in case this is something simple like that. I'll ask them to re-upload
> those files. In the meantime, any other sleuthing suggestions would be
> greatly appreciated.
>
> Sincerely,
>
> Carrie Ganote
>
> ________________________________________
> From: Hans-Rudolf Hotz [h...@fmi.ch]
> Sent: Wednesday, March 12, 2014 5:07 AM
> To: Ganote, Carrie L
> Cc: galaxy-dev@lists.bx.psu.edu
> Subject: Re: [galaxy-dev] History seems to load forever
>
> Hi Carrie
>
> Was the history which is causing troubles created before you switched to
> external authentication? Or has the user a slightly different e-mail
> address now? eg different use of capital letters, like 'foo.bar@home'
> and 'Foo.Bar@home'  - we had such problems, when we switched to external
> authentication.
>
> I had to dig into our MySQL database and fix the "galaxy_user" table. In
> your case, I recommend looking at the "galaxy_user" table and check
> whether the user has more than one entry. Take the "id" (ie the number)
> and search the "history" table using the id as 'user_id'. I would guess
> you can fix your problem by changing the 'user_id' in the "history"
> table for the history which is causing troubles.
>
> BUT, BE VERY CAREFUL! you can do a lot of damage to the database. Switch
> off the galaxy server first, and MAKE a back up the database before you
> change anything.
>
> Regards, Hans-Rudolf
>
> On 03/11/2014 11:58 PM, Ganote, Carrie L wrote:
> > Hi List,
> >
> > I just pulled and merged from galaxy-dist (I think it's dc067a95261d),
> > updated my database, and migrated my tools. The issues I am able to see
> > are minor, but I have a user who can no longer access a particular
> > history. It apparently just hangs. If they delete the history, Galaxy
> > responds, but it will hang again when they try to add back any datasets.
> > Unfortunately, I don't see any errors in the paster logs about this. I
> > fear that their dataset entries in the Postgresql db have been corrupted
> > during the update, or perhaps the files themselves were purged. I cannot
> > reproduce their issues with my own histories - I'm able to bring up
> > saved histories and upload etc. I don't know if they can share a history
> > if it can't be loaded. How should I troubleshoot this?
> > I'm set up to authenticate through apache, which makes it harder to get
> > in as the user and see what's up. Is there an easy way to find out what
> > histories belong to what users? I can search the database?
> >
> > Any advice would be greatly appreciated!
> >
> > -Carrie
> >
> >
> > ___________________________________________________________
> > 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/
>
___________________________________________________________
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/

Reply via email to