I think there may be a bug with regards the history/job associations
introduced in the upgrade. Many of the users have histories where the
associated jobs are no longer shown. The histories themselves still exit.
The problem seems to be mainly workflows with many jobs. The HistoryID/job
association is still in the database, though there is no history/dataset
association for these Histories (I havent investigated enough to know if
this is expected).
This is definitely a result of the upgrade and is reported by a number of
users. It does not occur for all histories - only some. The latest upgrade
does not help.
It appears that the ini file is hardcoded into manage_db.py. You may want
to make this an argument to the script as we have two different databases
from two different configs and were wondering why the wrong one was updated.
is there a way/module or data Library that allows users to access there
files WITHOUT the need of uploading them first? Cause our Galaxy
instance is running within the intranet, all files could be accessed
straight via NFS.
Thx, Michael ;-)
Hi there, I've realized that SAM tools in galaxy do not operate on BAM files... is there a reason for this?
Cogentech - Consortium for Genomic Technologies
via adamello, 16
And yet, I have some comments:
1. It seems the notification email is sent immediately when the workflow is submitted, before the job is completed.
I've only tested it a few times, but a for a workflow with 5 steps (each is a shell scripts that does "sleep 30") and the last step is configured with EmailAction - I get the email immediately, before the last step is completed.
2. users don't really need a 6-digits microsecond accuracy in the "completed time".
3. The subject line contains "%s", not replaced with a variable ( lib/galaxy/actions/post.py:77 )
4. The email line says "your job "X"..." but "X" is the history name. This implicitly assumes that users run a single workflow in a history, which is not the case.
A more common use case (in our local instance): users load 5 FASTQ files in a single history, and start 5 workflows on those files (all in the same history).
A friendlier message would be "You workflow 'X' on dataset 'Y' in history 'Z' is completed",
with X being the workflow name, and "Y" being the first dataset used as input in the workflow (if multiple files were used, take just one).
Also, remember that many (most? in my case) users still call their histories "unnamed history". So the history name alone isn't helping.
5. The time reported in the emails (for me) is not the local server time.
This might be an indication for a deeper problem (e.g. my postgres time zone is wrong).
6. Link to the galaxy server:
it's a good idea to say "at Galaxy instance XXX", but if I may ask for more:
instead of just the host name, use the complete "url_for()" link, so that mirrors that use the "prefix" option will contain the full link.
If you add "http://" prefix, most email clients automatically convert this to a clickable link (even in textual, non-html emails), so users will have easier time getting to galaxy.
Your job 'Unnamed history' at Galaxy instance rave.cshl.edu is complete as of 2010-06-29 23:18:53.271963.
Will be more helpful as:
Your job 'Unnamed history' at Galaxy instance http://rave.cshl.edu/galaxy is complete as of 2010-06-29 23:18:53.271963.
To ask for even more:
Construct a link that automatically switches to the relevant history - so users will get to their completed jobs with a single click.
1. There's no way to look at hidden datasets (you've mentioned that you're working on that).
2. Hidden datasets are still counted on the "history list" view - a bit confusing (but I'm not sure I have a good suggestion, because of the next item).
3. Two useability issues with hidden datasets:
A long-running job whose dataset is hidden is confusing.
Imagine a workflow with a paired-end mapping job that is hidden - it could take hours, but the history pane will show nothing: only green datasets (the previous workflow steps) and grey datasets (those that haven't run yet).
A failed hidden job (didn't test it, just thought about it):
If a hidden job fails, its following (unhidden) job will also fail, but it would not be immediately obvious how to get to the origin of the failure.
It might be more useful if all datasets are displayed until the entire workflow is successfully completed, and only then datasets are hidden (some sort of an automatic post-action on the last workflow step).
If any step in the workflow fails (or if the workflow isn't completed yet) - everything is visible (I must admit I don't have a good solution for a workflow with multiple final outputs).
Would be great to be able to use templates/variables in the new name (e.g. "$input"), so that each step could contain parameters or the name of it's input. (Remember that my users run the same workflow multiple times in the same history, so a fixed name will create multiple datasets with the same name - a bit confusing).
Would be great to be able to change dbkey/organism as well (in addition/alternative to columns/filetype).
Keep up the good work!
I want a float parameter which is optional, so the field displayed to
the user is blank, and validated as float if user enters a value, i
<param name="abc" type="float" optional="True" value="" label="a number" />
but get the "A real number is required" error.
Looking in the code, "class FloatToolParameter( TextToolParameter )"
it seems like the optional parameter handling is missing.