Arvados

22235-toolbar-access-fixes @ de29bf7e3872c4e21f7c94a20872b705c101b0ec

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

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

• A new toolbar/context menu kind was created for the writeable, non-admin cases: the writeableProject and writeableCollection kinds.
• A bug cropped up where if a new toolbar populated with the same exact options as the previous toolbar, a few of the buttons would overlap during the transition and be forced into the overflow menu. To fix this, I memoized the toolbar actions and implemented a 100 ms debounce for the transition.

22235-toolbar-access-fixes @ 03763baac17807d033414ab999437b8c1e53f20c

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

✅ Regular user, frozen project. User should have the "share" and "un-freeze" icons. The context menu has the same problem.

✅ For sharing: if the user has manage access (or is an admin), the "Share" icon should always be available on projects.

✅ For unfreeze: the logic is (if the user is an admin) OR (user has manage permission AND API.UnfreezeProjectRequiresAdmin === false)

✅ Regular user, all processes view. The container request is writable (user can write to the parent project), so "Edit" and "Remove" icons should be present. They are present in the context menu, but not the toolbar.

• It is worth considering that a refactor of the menu item selection process is already planned, in which many of the fixes on this branch will be obsolete or overwritten.

process-middleware-service.ts:56

            select: [...containerRequestFieldsNoMounts, "canWrite", "canManage"],

This should be can_write and can_manage

But there's a second problem:

            const params = this.getParams(api, dataExplorer);

            // Get items
            if (params !== null) {
                const containerRequests = await this.services.groupsService.contents('',
                    {
                        ...this.getParams(api, dataExplorer),
                        select: containerRequestFieldsNoMounts.concat(containerFieldsNoMounts)
                });

It's replacing the select field so the can_write and can_manage still don't get sent in the actual query.

Also, as noted on matrix, looks like you missed note-11 about the Groups toolbar.

22235-toolbar-access-fixes @ 2cbfdab7bb07950b953d99713c77a998b2c024df

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

But there's a second problem...

I had fixed this elsewhere but then made these change to pass e2e tests. I then neglected to make sure the result was the same, but it's fixed now.

Groups table now shows proper toolbar menu.

Ticket #22276 was created as a follow-up

LGTM! Thank you!