Request to add more details for tools that fail because user is not logged in

[martenson]

From Bob Harris:

Maybe more detail in a sentence accompanying "Please log in to use this tool" would get a few users to the solution and cut down (a little) on problem posts.

Example bug report details when this occurs:

GALAXY TOOL ERROR REPORT
------------------------

This error report was sent from the Galaxy instance hosted on the server
"https://usegalaxy.org/"
-----------------------------------------------------------------------------
This is in reference to dataset id XXXXXX from history id XXXXXX
-----------------------------------------------------------------------------
You should be able to view the history containing the related history item

3: Lastz on data 1: mapped reads

by logging in as a Galaxy admin user to the Galaxy instance referenced above
and pointing your browser to the following link.

https://usegalaxy.org/history/view?id=XXXXXXXXX
-----------------------------------------------------------------------------
The user 'XXXXX' provided the following information:

Hi,
    My name is XXXXX, a postgraduate student from the University XXXXX. I am a novice in bioinformatics however I have just began making use of your server.
I have got a fa file containing more than 50000 nuclotide. I tried making use of the Lastz tool to map against a reference sequence i obtained from NCBI. I keep getting error messages following execution.
Please what could be the problem??
Hope to hear from you..thank you
-----------------------------------------------------------------------------
job id: XXXXXXX
tool id: toolshed.g2.bx.psu.edu/repos/devteam/lastz/lastz_wrapper_2/1.2.2
tool version: 1.2.2
job pid or drm id: None
job tool version: None
-----------------------------------------------------------------------------
job command line:
None
-----------------------------------------------------------------------------
job stderr:

-----------------------------------------------------------------------------
job stdout:

-----------------------------------------------------------------------------
job info:
Please log in to use this tool.
-----------------------------------------------------------------------------
job traceback:
None
-----------------------------------------------------------------------------
(This is an automated message).

[nsoranzo]

I'm not sure there's much we can do about this.

[jxtx]

It seems odd that this would fail at runtime. If a tool requires the user be logged in, don't let them run it in the first place.

[nsoranzo]

I suppose this is a Galaxy Main issue, ack-grep "Please log in to use this tool." returns nothing.

Probably a dynamic job destination which requires the user to be logged-in to use lastz?

[hexylena]

We have dynamic job destinations like this too. Hiding the tool from the UI for non-group users is one thing, preventing them from running it (as far as I can remember) requires custom job destinations.

[nsoranzo]

Should this be moved to Trello then?

[jmchilton]

Edit: Previous comment was wrong - this is all happening in a dynamic job destination I guess. Hmm...

So one of two things

• the dynamic rerunning routed an anonymous user to a destination that required them to be logged in (should be easily preventable I guess by updating the rules) or
• the user selected an invalid option in the job submission hints for lastz (in which case - we should update that code to allow specifying certain options require the user to be logged in - maybe separate forms for logged in and anonymous users).

[jmchilton]

Yeah - lastz always gets routed to stampede and that destination requires you to be logged in. https://github.com/galaxyproject/usegalaxy-playbook/blob/master/files/galaxy/common/dynamic_rules/multi_dynamic_walltime.py#L85

@natefoo - ideas? Should we allow overriding the attribute that indicates being logged in is required from tool_conf.xml maybe?

[natefoo]

@jmchilton That'd work. I don't have a strong opinion on the implementation.

[hexylena]

@jmchilton would it be possible to run the job destination code multiple times? Dry-runs during tool form filling out, and then again, during normal submission?

I'd make use of the "Please log in" feature, but I'd find it significantly more useful if it returned the error code from the job destination. E.g. my job destinations that disable anonymous users from submitting large input files to certain tools. Would be a bit better end user experience.

[jmchilton]

@erasche It is a fair request, but it is pretty niche so I am not sure it is on the immediate horizon. The next time I take a stab at working on the dynamic destination code though I will try to keep this request in mind.

[jennaj]

Maybe the time is right to revisit this?

There are many new tools with complex inputs. Even existing tools (beyond Lastz) trigger errors due to input issues that could be trapped with 'self-help' feedback, real time, to limit the ask-and-wait factor for custom support through bug reports/Biostars/mailing lists. Input issues still top the list for the most common reason for tool failures.

I very much like the "Dry run" idea. This is a win for any running/hosting a Galaxy server (locals included) (e.g. obviously problematic inputs are detected quickly, reducing the number of jobs fully submitted and using compute resource that are doomed for eventual failure) and a win for our community of users (both long time Galaxy users - and new. Everyone makes small input errors from time to time, reguardless of experience level).

Our support experiences and prior reports of issues clearly demonstrate that this is true for not only new tool all are figuring out how to use optimally, but also existing tools used over time successfully in prior analysis with a new set of inputs and (important but sometimes under the radar) re-runs that involve tools/dependencies/expected-inputs that have evolved over time. We all know that this is how real-life analysis goes - Bioinformatic or otherswise - within Galaxy or otherwise.

Even if the tool feedback about errors is not entirely specific (this seems unlikely for certain routine input problems, but there are many input problems we could detect outright). Enhanced support about how to go about troubleshooting is certainly something we could choose to do and I think we should strongly consider. Links to support Q&A and the like could be a partial solution. I plan to re-organize and expland the most common help advice (from all support channels) in the updated wiki for this purpose. The goal is make each very short and to the point, with gory details available for those digging deeper. Placing these as links directly in the UI - with brief text from the Q&A (or FAQs, or however we decide to label), built-it on the form next to the input options as "?" pop-ups would/could be part of the overall friendliness factor as the UI matures.

That's the lobby and I would contribute in the areas of UI design ideas, providing specific help content (UI and link-outs), and the like - whatever I can do. Should we make a new general ticket for the ideas others have brought up and that I have added to here? Discuss and organize into manageble chunks. I don't see it is not all or nothing, but rather some now, some later - where each is prioritzed in terms of real measurable impact on the user experience -tracking the actual, verus expected- 1) reduction of repeat support questions and 2) actual compute-for-naught impact). This is a larger effort involving more than Lastz. (But link this ticket in - it serves as an excellent practical example from Dr. Harris :) ) I would go so far as to suggest we consider the 'why bother priorizing now' rational as fitting well into Galaxy's broader "Accessibilty" goal.

We can discuss - here or in another venue. My focus is support so I am definately biased (disclaimer!). Our project most certainly has other priority goals that need to be considered and balanced against these ideas plus other forward-looking ideas (in progress or under dicussion) that will shape the Galaxy experience over time.

Thanks all!