Arvados

Changes at arvados|393f785a96ad789983c6c153b1ff2425b414418e branch 22202-delete-process-navigation
Tests developer-run-tests-services-workbench2: #1321

• All agreed upon points are implemented / addressed.
  • Bumped rollup for dependabot
  • Changed the delete action to delete in parallel instead of sequentially
    • This allows grouping the notifications, instead of a success/error snackbar for each item it shows a separate one for each status (success, access denied, generic error) with a count if more than 1
    • Also changed refreshing DE to once after all deletions finished
  • Added check for current process being open, navigates to home project
  • Broke one cycle of imports by moving get project panel uuid to a file that doesn't import workbench actions
    • There are some obvious import loops in workbench actions but commenting out the obvious ones didn't fix the unit test run so I went with this solution since the alternative is going through each of the imports in workbench-actions, of which there are too many. DPDM also didn't seem to list the specific import loop path I was tracing though it had many going through workbench-actions
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • none
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • manually tested deletion notification grouping, added cypress tests to verify navigation to home and DE refresh in the project panel WF tab
• Documentation has been updated.
  • n/a
• Behaves appropriately at the intended scale (describe intended scale).
  • no change
• Considered backwards and forwards compatibility issues between client and server.
  • none
• Follows our coding standards and GUI style guidelines.
  • Improved by doing away with the "starting to remove" snackbar and grouping the final result notifications

22202-delete-process-navigation @ 4c8c6d12cfd31b8613f4498650b027b354f9db1b

This looks good, but going to the root project seems disruptive. Could it invoke a "back" navigation? And/or navigate to the parent project (when then history is empty).

There seem to be some challenges with navigating back - there is no way to check if there is history to go back to, you can see the history length but not know where in the history you are. The browser's landing page can also count as history so even if you could know that history.back() works you could be directing away from WB (if someone navigated from somewhere else directly to a process link and then deleted the process).

Navigating to the parent project seems more doable, but could require more error checking. I think currently you usually have at least read access to the parent project but I think it would be possible to create a permission link directly to a process, which would cause a navigateTo error - if we want to handle that case, I can change navigateTo to return success and have it navigate to home project on failure. I think that may be the best way to handle it.

Changes at arvados|d3a2ed445a3ef4e45b4158e1049ddf5f3e690166
Tests developer-run-tests-services-workbench2: #1324

• Changed delete process to navigate to parent project on success if currently viewing the deleted process
  • In the current system you can't grant permission to just a process so we assume they have access to the parent project
• Added delete process in subproject test

Stephen Smith wrote in #note-7:

Changes at arvados|d3a2ed445a3ef4e45b4158e1049ddf5f3e690166
Tests developer-run-tests-services-workbench2: #1324

• Changed delete process to navigate to parent project on success if currently viewing the deleted process
  • In the current system you can't grant permission to just a process so we assume they have access to the parent project
• Added delete process in subproject test

LGTM.