Arvados

• We are currently using the "InsertLink" icon (https://mui.com/material-ui/material-icons/?query=link&selected=InsertLink) for copying full URLs to the clipboard, we will continue doing that
• We are currently using the "FileCopyOutlined" icon (https://mui.com/material-ui/material-icons/?query=file&theme=Outlined&selected=FileCopyOutlined) for copying ids
• We also use FileCopyOutlined to mean "copy collection"

"copy uuid" on the toolbar, we would like to use "FileCopyOutlined" but it conflicts with "Copy Collection"

So that means we need to change the icon used for "Copy Collection".

• Use "LibraryBooksOutlined" as the copy collection icon on the toolbar.

https://mui.com/material-ui/material-icons/?query=library&theme=Outlined&selected=LibraryBooksOutlined

• Because "LibraryBooks" is currently used as the icon for collections, change the standard "Collection" icon to "Description".

• Change the icon used to copy ids (currently FileCopyOutlined) to "ContentCopy"
  • E.g. the values in the right side "Details" panel
• That means the icon used to copy the uuid on the toolbar will also ben "ContentCopy"

New plan:

Change the icon used to copy ids (currently FileCopyOutlined) to "ContentCopy"

E.g. the values in the right side "Details" panel should also be using "ContentCopy"

Then the icon used to copy the uuid on the toolbar should also be "ContentCopy"

Design principle is to use "Link" when it copies a full URL and "ContentCopy" when it copies a UUID.

22207-icon-resort @ 2dee3c8d68af8e561454fe829fc41cf6475fea6c

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

• ✅ All agreed upon points are implemented / addressed.
• - 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.
  All direction was from the stakeholders
• - Documentation has been updated.
• ✅ Behaves appropriately at the intended scale (describe intended scale).
• ✅ Considered backwards and forwards compatibility issues between client and server.
  No change
• ✅ Follows our coding standards and GUI style guidelines.

• There is a reference to "Copy Link To Clipboard" items for Workflow runs, but that menu item didn't previously exist and there was no mention of implementing it, so I assumed it was a mistake.

Lisa Knox wrote in #note-18:

22207-icon-resort @ 2dee3c8d68af8e561454fe829fc41cf6475fea6c

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

• ✅ All agreed upon points are implemented / addressed.
• - 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.
  All direction was from the stakeholders
• - Documentation has been updated.
• ✅ Behaves appropriately at the intended scale (describe intended scale).
• ✅ Considered backwards and forwards compatibility issues between client and server.
  No change
• ✅ Follows our coding standards and GUI style guidelines.

Notes:

• There is a reference to "Copy Link To Clipboard" items for Workflow runs, but that menu item didn't previously exist and there was no mention of implementing it, so I assumed it was a mistake.

There should be a "Copy Link To Clipboard" for workflow runs, so I think leaving it out was an earlier oversight. Please add that.

I think this is pretty good, just one thing I noticed:

When opening the overflow menu, the tooltips appear below the item. When you move the pointer down towards the next item, the tooltip is still visible, as a result the pointer wants to interact with the tooltip from the previous item instead of hovering over the next item.

To fix this, I propose adding placement="left-end" to only the tooltips that appear in the overflow menu.

We don't want to use that placement for the horizontal toolbar, otherwise we just have the same issue. The tooltip needs to appear somewhere out of the way of the direction of motion of the pointer along the menu.

22207-icon-resort @ a0a90345d5be7cc969236b76543ba99ca76e56ef

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

There should be a "Copy Link To Clipboard" for workflow runs...

added

When opening the overflow menu, the tooltips appear below the item...

Done

To fix this, I propose adding placement="left-end"...

I chose left-start instead of left-end because it had better vertical alignment with the list items

Also, I noticed that when a project is frozen, the "Share" button (in both the toolbar and context menu) is in a subsection all by itself. At first I thought something was broken, but it's just how the new sorting plays out. It looks kinda funky to me, but I can't really think of a way to improve it, and it doesn't necessarily need to be changed.

Found #22236, we'll fix it on this branch.

Also, I noticed that when a project is frozen, the "Share" button (in both the toolbar and context menu) is in a subsection all by itself. At first I thought something was broken, but it's just how the new sorting plays out. It looks kinda funky to me, but I can't really think of a way to improve it, and it doesn't necessarily need to be changed.

So, I also noticed that buttons that require "can_write" access (edit, move, etc) are showing up for collections and container requests within frozen projects as well. So I'm suspicious of how workbench determines what is writable. Made a separate ticket #22235 .

I'm leaning towards removing the first divider.

Also, we need to systematically go through and check that all the toolbars are correct for each of admin, can_manage, can_write and can_read access levels, I'm working on that in #22235 .

22207-icon-resort @ 95912249e8123984c95a40ca6ee547448349be8d

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

Fixed #22236, removed first divider, and adjusted some of the toolbar css

22207-icon-resort @ d64e7cb73967f012da2e0ed4ad9caa3303b2d329

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

The bug where the toolbar overflows into the search input has been there for months, apparently. We never noticed it because until now, the search input and the toolbar were on separate 'rows'.

Additionally, the struggle to fit all of the things we want to fit above a data explorer has been going on for way too long, so I made some executive decisions here that I think will just straighten this out for good.

• The process progress bar is moved to be above all the other items in the Project view and to below all the other items in the 'subprocess' and 'run history' panels.

This solves every other layout problem with the toolbar on this ticket and (hopefully) prevents us from having to revisit this area again, because moving the progress bar out of the way means that everything else we want to fit in that space actually has the room to fit there.

The decision to move the progress bar up in the project view and down in all other views was a purely aesthetic one. Moving them all up or down looked unbalanced to me.

22207-icon-resort @ a3f995fc2085c067f7b2ba2cd2d48e8ab2e40bce

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

merged main into this branch

22207-icon-resort @ f04703e79c0095e6b6ef96b0262d81fc5316df63

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

Done

Lisa Knox wrote in #note-31:

22207-icon-resort @ f04703e79c0095e6b6ef96b0262d81fc5316df63

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

Done

LGTM!