Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WX-1734] Workflow permissions modal #5096

Merged
merged 69 commits into from
Oct 10, 2024

Conversation

kpierre13
Copy link
Contributor

@kpierre13 kpierre13 commented Sep 20, 2024

Jira Ticket: https://broadworkbench.atlassian.net/browse/WX-1734

Summary of changes:

What

  • Adding a permissions modal to the workflows pages

Why

  • Firecloud UI to Terra UI migration

Testing strategy

  • Manual testing
  • Unit tests
Screen.Recording.2024-10-03.at.4.03.25.PM.mov

Since the video was recorded, the modal was updated with a warning as shown below:
modal with user groups warning image

@broadbot broadbot requested a deployment to pr-3 September 23, 2024 14:27 Abandoned
@sam-schu sam-schu self-requested a review September 23, 2024 15:28
src/pages/workflows/workflow/common/PermissionsModal.tsx Outdated Show resolved Hide resolved
src/pages/workflows/workflow/common/PermissionsModal.tsx Outdated Show resolved Hide resolved
src/pages/workflows/workflow/common/PermissionsModal.tsx Outdated Show resolved Hide resolved

return (
<Modal
title={`Permissions for ${workflowOrNamespace} ${namespace}/${name}`}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few notes here:

  • It is easy for this title to cut off at the end. With the export modal, we dealt with this by deciding to remove the name of the specific method being exported from the title.
  • We should make it clear for the "workflow" case that viewing and editing permissions happens per-snapshot, not per-method.
  • If we still want "workflow" in the title, can we use "method" instead for display?

Copy link
Contributor Author

@kpierre13 kpierre13 Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I can definitely update the title to un-include the actual name of the workflow, but I since the namespace/name is at the end of the title, I could also potentially add ellipses to deal with any overflow. What do you think?
  • What do you mean by "make it clear"? Did you have an idea of what this should look like?
  • Yes, now that we've decided to use the word method as opposed to workflow, I'll update this naming as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ellipses work automatically already, and often are needed even for short method names. Firecloud UI has the title as Permissions for Workflow namespace/name/snapshotId, which I do think is a bit confusing, but in Firecloud the title is very unlikely to be cut off. I think something like Edit snapshot permissions or Permissions for snapshot namespace/name/snapshotId could work, depending on whether you want to keep the method name in the title — even if we had the snapshot ID at the end, I wouldn't want the user to see Permissions for method namespace/na... with the snapshot ID cut off and assume that they were editing permissions for all snapshots of the method, when their changes would only actually affect the current snapshot.

<FormLabel id={id} style={{ ...Style.elements.sectionHeader, margin: '1rem 0 0.5rem 0' }}>
User
</FormLabel>
<TextInput id={id} placeholder='Add a user' value={searchValue} onChange={setSearchValue} />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Firecloud UI version of this modal validates that your input is a valid email address. We need this here to avoid:

  • having an error appear outside the modal and losing your progress if you add a non-valid email address and then attempt to save.
  • being able to enter "public" into the box, press Add, and then save to make your method snapshot public in an incredibly confusing way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can definitely add some email validation, similar to what we have in other places. And thank you for catching the 'public' option. I'll make sure to add that in so users can mark their methods as public!

setPermissions(append({ user: userEmail, role: 'READER' } as RawWorkflowsPermissions));
};

const save = withBusyState(setWorking, async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we refresh the page or reload the necessary data after a successful save so that the information on the right side of the page will be up-to-date without having to manually reload?

}}
/>
</div>
<Clickable
Copy link
Contributor

@sam-schu sam-schu Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also disable the remove button for the current user. (I appreciate having this button instead of having to choose "NO ACCESS" in the dropdown, though!)

Copy link
Contributor Author

@kpierre13 kpierre13 Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. As an additional note, once I can utilize the kebab menu, a Reader will also not be able to edit permissions like in FCUI.

);
};

export const PermissionsModal = (props: WorkflowPermissionsModalProps) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also have the "publicly readable" checkbox to edit public permissions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Thanks for catching!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for naming this file differently?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean — the name is different in reference to what?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems files are usually named in camel case pattern and this one is named with all lower case letters and with - in it. Maybe it can be named as WorkflowsAclUtils?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that this file name is modeled off of src/pages/workflows/workflow-utils.ts, whose name in turn likely follows the convention of all the utils files in packages/core-utils/src. If you think we should not be following the pattern from that directory, I can rename this file now, and then we can rename workflow-utils.ts as part of this ticket.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I didn't know about that existing pattern! In this case ignore my suggestion.

@@ -0,0 +1,16 @@
export interface RawWorkflowsPermissions {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find Raw in the name a little confusing. What do you think about WorkflowUserPermissions or WorkflowPermissionDetails?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also found the name confusing at first, but I was not sure if there was a reason for it related to the permissions structure in Agora. I can definitely change it to WorkflowUserPermissions.

onClick={onEditPermissions}
>
{makeMenuIcon('cog')}
Edit permissions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to delete option, can this be renamed to Edit snapshot permissions to make it more clear that this only updates permissions for selected snapshot?

@salonishah11
Copy link
Contributor

salonishah11 commented Oct 3, 2024

When testing, I was able to "add" a user even though it was already on the Current Users list. Do you think it is possible to be able to add some form of validation and disable the Add button when an email id entered is is already on the list? Also, in the below screenshot, Rocket was already an Owner on the snapshot. When I added the same user again it was defaulted to Reader. Clicking on Save changed the permission for Rocket to Reader.

Screenshot 2024-10-03 at 5 29 36 PM
Screenshot 2024-10-03 at 5 30 39 PM

@salonishah11
Copy link
Contributor

Similarly, if I am logged in as Rocket Raccoon and I am an Owner of a snapshot, I am able to "add" myself again in the Current Users list with Reader permission. I can't edit my own permission in the modal and hence clicking on Save throws an error correctly from Agora stating that I can't edit my own permissions. It would be good to add validation around not being able to add pre-existing user to avoid this error from Agora.

Screenshot 2024-10-03 at 5 51 26 PM

Screenshot 2024-10-03 at 5 51 45 PM

@sam-schu
Copy link
Contributor

sam-schu commented Oct 4, 2024

Re: the two comments above by @salonishah11 — I also noticed when testing the original version of this modal that you could add the same user multiple times. Following the precedent from our decision regarding the "delete snapshot" button's being enabled even when a user does not have sufficient namespace permissions, I did not fix this behavior because it is also present in the original Firecloud UI modal. However, your second comment highlighted an especially undesirable case that I had not found before, and it should not be very time-consuming to implement a fix, so I will add validation to avoid these issues.

@sam-schu sam-schu dismissed their stale review October 4, 2024 17:13

This PR is now a shared effort between Katrina and I, so I am not considering my own review to count as an approval.

Copy link
Contributor

@salonishah11 salonishah11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small nit regarding file naming otherwise LGTM

Copy link

sonarcloud bot commented Oct 10, 2024

@sam-schu sam-schu added this pull request to the merge queue Oct 10, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Oct 10, 2024
@sam-schu sam-schu added this pull request to the merge queue Oct 10, 2024
Merged via the queue into dev with commit adbf363 Oct 10, 2024
10 checks passed
@sam-schu sam-schu deleted the wx-1734-workflow-permissions-modal-kp branch October 10, 2024 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants