Arvados

Couple of implementation notes for this:

• Let's use MPVContainer/MPVPanelContent for the data tables
• Can we add a mode to the MPVContainer to make it behave like a tab control, so that clicking on one of the navigation buttons shows that panel and hides all the others? I think this would allow us to play with tabbed vs multi-panel behavior without having to rewrite everything.

From user feedback:

Step 1 is to add a "All" tab that has the existing combined view with minimal changes.

Step 2 Remove Data collections and Subprojects as distinct tabs.

Step 3 make the "Workflow runs" tab use "Process list" control on the project page (the base control used for all processes, subprocesses, etc. It should include the progress bar.)

We might end up with the tabs called "Data" and "Workflows"

I will check with the users to see how they feel about this change of separating out "Data" and "Workflows"

I'm going to make a new wireframe and share it to see how they feel about it.

The idea is to split out workflow runs and retain the the combined view for everything else -- that should be less disruptive.

Moved into a separate ticket (#21623): displaying filters active on a table as chips on the header

From discussion: limit this to a "Data" tab (which is everything except container_requests) and a "Workflows" tab (which is container requests)

Changes at arvados|e7dfc4d7e4d90dded7e0c6d1bd656c382b4d764d branch 21225-project-panel-tabs
Tests developer-run-tests-services-workbench2: #903

• All agreed upon points are implemented / addressed.
  • Added mutually exclusive tabs mode to MPV view
  • Moved project panel middleware code into project panel data
  • Added workflow runs tab
    • Remove process runs from data tab & filter options
    • Rename main/sub processes to Workflow Run / Step
  • Removed process-related columns from data tab
  • Added support for projects to process progress bar and add to run tab
  • Added support for multi select bar to operate in single select mode in runs tab
    • I noticed that the Multi Select bar was forced to always be in multi select mode (even when single item selected) whenever the toolbar isn't in the title bar (whenever there is a panel title or progress bar)
    • This "always multi select" mode is relied on in several places to keep the toolbar empty of options when a single item is selected (eg. due to there being no multi-select options for a specific resource type such as users on the users panel, and forcing multi select mode prevents the single select options - which don't work for that resource type - from showing resulting in an always empty toolbar).
    • Instead of overhauling that logic I opted to preserve the existing behavior and change the runs tab multi select toolbar to operate in normal single or multi select mode by adding forceMultiSelectMode to any consumer with a title/progress bar and already relied on operating in only multi select mode
    • I also noticed a bug with the All Processes panel where deselecting an item doesn't remove the multi select toolbar's selection, opened #21883
  • Updated wait-on dependency for security - it only seems to be used in the run-integration tests and the latest version seems to support all the cli args we use
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • #21883
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • Updated tests to use tabs
• Documentation has been updated.
  • n/a
• Behaves appropriately at the intended scale (describe intended scale).
  • no change in scale
• Considered backwards and forwards compatibility issues between client and server.
  • n/a
• Follows our coding standards and GUI style guidelines.
  • done

As discussed, playing around with this in the browser looks good, so let's just get Lisa's feedback on the code.

• I know I wasn't meant to review the aesthetics, but I see a lot of vertical whitespace and I think adding something like
  borderBottom: `1px solid ${theme.palette.grey[300]}`,
  to the 'tabs' css class would help a lot, just a suggestion.

• I was curious what forceMultiselectMode was for, and I think it has something to do with the lack of multiselect filtering in place for "Workflow run" or "Workflow step" resources, am I right? If so, I wonder if forcing multiselect mode is a better approach, what do you think?

Otherwise, it all LGTM

Changes atcommit:arvados|4d3bc1e278189f3939146a7e988b1fb488d060b7 21225-project-panel-tabs

• Added, I like that it helps distinguish the non-selected tab from the content.
• The forceMultiSelectMode is actually the existing isSubPanel parameter, I renamed it because I wanted the parameter to reflect the effect that it actually has, and since I needed to turn it off on the runs tab where it would normally be forced on due to the progress bar/title making it a "subpanel" like how it is in the subprocess panel. As it was, any time a title/progress bar is present, it would use the second multi select toolbar which was hardcoded to isSubPanel=true which forces the selection to be empty until multiple items are selected, which isn't what we want since the runs tab should behave similarly to the all processes tab. I hope that make sense.

That makes sense, thank you. Everything LGTM!