configurable n-window #864
Comments
Yeah that's definitely on the wanted list. |
Note: This will require data provision on the backend (the same provision required for |
|
The n-window also has a role in managing "offline" (historical) task/job information since See also: cylc/cylc-uiserver#378 |
|
Blocked by cylc/cylc-flow#5609 and limitations of the currently algorithm which cause it to miss cousin nodes. |
|
Just looking through and saw this one. The Issue you had blocking this is closed, is this still blocked? |
|
Thanks for the heads-up, this should be unblocked now, but @oliver-sanders can confirm. |
|
Yes this is no longer blocked. It should be relatively easy to get working, I got a prototype working in a few lines. |
|
This would be really useful in a rose-stem context which doesn't cycle and that people want to repeatedly rerun certain tasks that may otherwise would have fallen out of scope. |
|
This will be very useful for most contexts, unfortunately, we haven't had the time to work on it so far. |
* Closes cylc#864 * Add a selector for switching the n-window extent between 0 & 3 inclusive. * The n-window value appears to be preserved when navigating back to the workflow.
* Closes cylc#864 * Add a selector for switching the n-window extent between 0 & 3 inclusive. * The n-window value appears to be preserved when navigating back to the workflow.
* Closes cylc#864 * Add a selector for switching the n-window extent between 0 & 3 inclusive. * The n-window value appears to be preserved when navigating back to the workflow.
Ideally the user would be able to set the
n-windowfor each view independently.A good use case would be an operator working on a complex workflow. They might want the tree view in
n=1and the graph view inn=0.One day we would be able to construct an n-window around an arbitrary selection of start tasks which would enhance this further.
E.G. The operator could have the tree view open to
n=1and the graph view to ann=2based around the tasks they are selecting in the tree view.This would be useful in understanding the impacts of task failures, delays, bottlenecks, etc.
This is a complex thing to do and would require server-side assistance. I think the data store currently supports the concept of an arbitrary n-window selection.
Related:
Pull requests welcome!
The text was updated successfully, but these errors were encountered: