Need to better handle sequential incremental updates
Currently we block incremental updates at an organization level in the UI. We need to do one of the following instead:
- Queue the subsequent incremental update task, and somehow handle any errors or no-ops that arise after the first has completed.
- Only show systems that the incremental update can actually be applied to in the system selection step. We'd also want to show a list of systems that cannot be updated and explain why.
Option #2 is likely a lot easier than option #1 and is not blocked on dynFlow supporting queuing (as #1 is).
#9 Updated by John Mitsch 10 months ago
- Target version deleted (
- Status changed from New to Rejected
Thanks for reporting this issue. This issue was created over 4 years ago and hasn't seen an update in 1 year. We are closing this in an effort to keep a realistic backlog. Please open up a new issue that includes a link to this issue if you feel this still needs to be addressed. We can then triage the new issue and reassess.