Thanks @innovate-invent ! I knew that would be a useful papercuts call. :-)
And bravo on the issue number too
selten
@selten
@innovate-invent with replacing the loc files, do you mean the data table data?
Nolan Woods
@innovate-invent
@selten yes
selten
@selten
@innovate-invent I have already worked on getting that one sorted (albeit for a different reason) and will continue with the suggestions soon, so that one is already being taken care of (galaxyproject/galaxy#9875). I'm currently waiting for a proper development laptop to arrive so I can continue working on it.
Nolan Woods
@innovate-invent
@selten excellent! thanks
do you mind linking that in the issue?
others are also interested in following the progress
selten
@selten
I did
@innovate-invent I'll let you know when the PR is done, I hope to have it in the 21.05 release
Nolan Woods
@innovate-invent
brilliant! :thumbsup:
pvanheus
@pvanheus
as a usability tweak... when I search for a dataset in the multi-history view, I would like to only see those histories where the search has a hit, rather than see a whole lot of empty histories that I need to scroll though. I think this might be a not-too-hard thing to tackled, but can someone point me to where to start in the code?
Nolan Woods
@innovate-invent
@pvanheus that is likely a @nerdinacan question. He is in the process of rewriting the history view and may have already addressed this.
Mason
@Nerdinacan
@pvanheus I haven't actually built the multi-history view yet, but you could try mounting the History/HistoryPanel multiple times. The intent was to separate a history component from the fact that the history being shown is "the current one" so we should be about ready to try and build that view.
As for finding histories that contain a text-match of a contained dataset, that is likely going to require a separate search ajax call which youwould use to determine which histories to try to render. That roughly the functionality you're looking for?
At any particular time a history component doesn't necessarily know the entire contents of all its datasets, because that could be a whole lot of datasets. So you will need to do that filter you described first, then render any matching histories in a loop.
Mason
@Nerdinacan
You could, however, search the local cache for all datasets matching your criteria, then get a unique set of histories. This will only work on data that has already been cached. This might be an acceptable "loading state" while your main query goes and gets an exact answer.
pvanheus
@pvanheus
thanks, @Nerdinacan. where in the codebase is this stuff?
Mason
@Nerdinacan
@pvanheus The beta history component is in client/src/components/History, although a somewhat cleaner version is just about to hit dev (galaxyproject/galaxy#10971)
You would probably be interested in the HistoryPanel component. Probably you'd do some kind of history query/filter with the ajax call I mentioned, then try to loop over the results and render a HistoryPanel with each history object? I genuinely haven't tried it yet though
pvanheus
@pvanheus
I'll have a poke at it thanks...
I use Galaxy with IRIDA quite a bit and IRIDA has a way of making many histories... thus the interest.
Mason
@Nerdinacan
awesome let me know how it flies, again, I'm still trying to get that component happy before I start slapping more on the page. :)
I don’t think that is a work around - I think it is the right approach. If we’re going to pick apart collections - capturing it with that tool seems the right thing to do to me
Conceptually, I agree with you. It's just that, practically, it forces you to generate a more complex history to get a nicer report.
1 reply
Björn Grüning
@bgruening
Agree concetually the correct thing, but it increases the complexity of the workflow and decreases UX (assuming the entire collection will be kept at the end). One of those cases ... :(
Yeah, that's another good point. It seems the WF editor doesn't let you label non-starred datasets. But without a label you cannot access the dataset in a report.
All this is still kind of acceptable, just making things a bit more complicated than necessary.
Marius van den Beek
@mvdbeek
Yeah … we need to break up labels and starring. They are not the same
Björn Grüning
@bgruening
I have the suspician that PDF export from reports yields to "sockets full" uwsgi messages.
Worth an issue?
Marius van den Beek
@mvdbeek
What makes you think that ?
Björn Grüning
@bgruening
We have made PDF export work an hour ago and since then I see many full sockets and Galaxy is not responding ;)
maybe just a coincidence, not sure, don't want to blame @wm75:matrix.org ;)