Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI trigger for RNAsum workflow #74

Open
reisingerf opened this issue Nov 11, 2024 · 2 comments
Open

UI trigger for RNAsum workflow #74

reisingerf opened this issue Nov 11, 2024 · 2 comments
Assignees
Labels
feature New feature or request

Comments

@reisingerf
Copy link
Member

A way to manually trigger RNAsum, similar to what's possible in the v1 portal, is still needed in v2.

@reisingerf reisingerf added the feature New feature or request label Nov 11, 2024
@alexiswl
Copy link
Member

This is probably something that requires a little bit of collaboration from my side to (i.e a lambda function to point at).

Given a subject id can we assume to use the latest versions of umccrise / dragen wts analysis runs?
If so, lambda should only need the subject id and the dataset and should be able to populate the ready event from that?

@reisingerf
Copy link
Member Author

In principle I am OK with whatever works. Just noting that there may be other options and that we don't need to cover all use cases from the start.

If I understand your question correctly, you'd try to infer the required input values given a subject ID only?
This will "hide" the inference in the back-end and it won't be visible to the triggering user. Not sure we want / have to go that way (yet).

For example: we'd usually have the default PANCAN run triggered automatically, right?
An option might be to only allow/support a "rerun" option, i.e. select that run in the UI and say "run this again, but switch the reference", then all required inputs should be present. It also means all required pre-conditions for running RNAsum are covered by default (as otherwise the initial run would not have gone through).
We'd only be supporting a very specific use case, but there should be no guesswork / inference needed and it's the most common use case (others could be handled manually until we have a better grip on them).

Or am I off the mark?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants