Arvados

22845-process-status-counts @ 0bc658b3d0f3d4f557fd9889f7d598c86d8fd57b
developer-run-tests-services-workbench2: #1514

• ✅ All agreed upon points are implemented / addressed.
• n/a Anything not implemented (discovered or discussed during work) has a follow-up story.
• ✅ Code is tested and passing, both automated and manual, what manual testing was done is described
• ✅ New or changed UX/UX and has gotten feedback from stakeholders.
• n/a Documentation has been updated.
• ✅ Behaves appropriately at the intended scale (describe intended scale).
• ✅ Considered backwards and forwards compatibility issues between client and server.
  • no changes
• ✅ Follows our coding standards and GUI style guidelines.

22845-process-status-counts @ 0a081f867dc4d3f031df11730c1b274313726f15

developer-run-tests-services-workbench2: #1515

Revised to account for the "Run History" panel in the Workflow view. The api call that gets the filter counts is conditionally replaced by its equivalent using template_uuid as a query param. Since it is one call replaced by another, there should be no noticeable difference in performance.

The one thing I noticed is that the rows with zero items don't show as zero, they don't show a count at all. I think this is the logic:

        {count ? `${name} (${count})` : name}

I'm wondering if what this was meant to check for was an undefined or null count (in which case you'd get () or (undefined) or (null) or something which would obviously be wrong) but since zero is also falsey it ended up taking the wrong branch as well. Maybe use type count == number ? Or was this an intentional choice?

I don't suppose the counts could be vertically aligned on the right (i.e. right-justified) (But don't kill yourself if it is annoying or you think it looks bad).

How hard would it be to enable this on the "All processes" panel? (The all processes view didn't have the "progress bar" before but this new way of displaying counts makes more sense to include).

Are there any performance implications of getting counts, e.g. if getting the counts takes 5 seconds because the database is really really big and slow, does that slow anything down on the frontend, or does it happen entirely in the background?

22845-process-status-counts @ aa342b1e0fe3b69e66cb51ef32f045d4c02303f3
developer-run-tests-services-workbench2: #1519

...Or was this an intentional choice?

It was an intentional choice, because it allowed me to completely ignore all cases where the count wasn't loaded and it also allowed me to be more general with the application, i.e. the same UI element can be used whether the count is implemented for that table or not. With the addition of the other tables though, (all tables where process statuses exist) the point becomes moot.

I don't suppose the counts could be vertically aligned on the right (i.e. right-justified) (But don't kill yourself if it is annoying or you think it looks bad).

Done

How hard would it be to enable this on the "All processes" panel? (The all processes view didn't have the "progress bar" before but this new way of displaying counts makes more sense to include).

Done, and the "shared with me" table as well.

Are there any performance implications of getting counts...

The loading takes place entirely in the background, and in #22127 the loading of each count was staggered so that control of the event loop is yielded between each fetch. The result is that on the largest tables (Shared With Me and All Processes) the counts take a couple of seconds to load but unless you open the status filter popover, you will never know it's happening. If you do open it, there is now a three-dots pulser to indicate loading.

On first load of the app: I go to my home project, click on the status filter dropdown, the counts all show as "loading" and never get populated. Closing the status popup and opening it again doesn't do anything. Interacting with the status popup (changing the filter) does cause the counts to appear. Going to a different project and looking at the status popup for the new project causes the counts to appear. This seems to be some first-time initialization issue.

If I change the "type" so it includes "workflow steps" in addition to "workflow runs" the counts in the status popup do not update, so the count provided by the table no longer matches the count provided by the status filter.

The "status" and "type" popups are inconsistent. The "status" popup doesn't have an explict "close" button, the "type" popup has "close" button at the bottom. Both of them close if you click outside the box. However, what I think would be most consistent with our other design would be to have a [x] in the upper right (instead of a button that says "close")

Could you increase the spacing between the status column on the left and the numbers on the right a little bit?

22845-process-status-counts @ 1b9c0f8e9b50fd6bb36d56507c4f695ad726800e

developer-run-tests-services-workbench2: #1524

On first load of the app: I go to my home project...

• the loading would actually succeed intermittently, fixed now

If I change the "type"...

• fixed

The "status" and "type" popups are inconsistent...

• Added a close button to the status filter popover and moved the close buttons in both popovers to the bottom right for consistency

Could you increase the spacing between the status column on the left and the numbers on the right a little bit?

• Increased margin between them by 10px

22845-process-status-counts @ c2d662a818aa1009a2701a8c492b94f9dcb7bf37

developer-run-tests-services-workbench2: #1526

Fixed a logic error that caused intermittent CORS errors due to requests being made before all of the necessary values are populated.

Lisa Knox wrote in #note-16:

22845-process-status-counts @ c2d662a818aa1009a2701a8c492b94f9dcb7bf37

developer-run-tests-services-workbench2: #1526

Fixed a logic error that caused intermittent CORS errors due to requests being made before all of the necessary values are populated.

This all looks great, LGTM!