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

Warn users about unrestricted roles being assignable by a restricted role #34499

Merged

Conversation

AddisonDunn
Copy link
Contributor

@AddisonDunn AddisonDunn commented Apr 24, 2024

Product Description

USH-4414

A role that does not have "full organization access" being able to assign a role that does increases security risk. This PR implements a warning about this sort of configuration in the role modal.

See this doc for UI pics/an example.

Feature Flag

No FF, but location restriction is only available at certain subscription levels.

Safety Assurance

Safety story

  • This only adds red highlights/warning labels, and shouldn't affect any business logic/actual functionality
  • Tested different situations locally

QA Plan

None

Rollback instructions

  • This PR can be reverted after deploy with no further considerations

Labels & Review

  • Risk label is set correctly
  • The set of people pinged as reviewers is appropriate for the level of risk of the change

@@ -0,0 +1,3 @@
.role-modal-warning { // Used in combination with Bootstrap's 'help-block'/'alert' classes
margin-bottom: 0px;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@biyeun I welcome your feedback on the way I tried to remove the bottom margin on warnings in edit_role_modal.html. I tried to follow the instructions here.

Copy link
Contributor

Choose a reason for hiding this comment

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

This feature seems like an example of doing field-level help: basically using help-block but not the alert classes. Docs are here: https://www.commcarehq.org/styleguide/b5/organisms/forms/#field-errors

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 see. I think the red text is still appropriate, but when I use help-block with text-danger it overrides the text color:

Screenshot 2024-04-25 at 10 21 03 AM

So I tried using my own specifier: link.

Or would it be better to use help-block and then add a custom specifier that overrides the text color? Does it matter? Trying to get a feel for best practices.

Also, didn't even realize I am working in Bootstrap 3 territory.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oops, I sent the B5 link by mistake. The B3 docs are here: you get the red text by applying has-error to an ancestor of the help-block.

Also, didn't even realize I am working in Bootstrap 3 territory.

Yeah, the vast majority of HQ is on B3, although that is rapidly changing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, gotcha. Thanks Jenny.

@AddisonDunn AddisonDunn marked this pull request as ready for review April 25, 2024 14:34
data.manageRoleAssignments = {
all: data.is_non_admin_editable,
specific: ko.utils.arrayMap(o.nonAdminRoles, function (role) {
return {
path: role._id,
name: role.name,
value: data.assignable_by.indexOf(role._id) !== -1,
value: ko.observable(data.assignable_by.indexOf(role._id) !== -1),
access_all_locations: role.permissions.access_all_locations,
Copy link
Contributor

Choose a reason for hiding this comment

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

This is an observable, right?

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 don't think it is, actually. Seems likeo is just a dictionary that was passed straight through.

Copy link
Contributor

Choose a reason for hiding this comment

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

huh, I see. I had thought it would need to be in order for the new markup to appear/disappear as needed when someone checks/unchecks full org access. You've confirmed that works, right?

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'm aware that it does not update without reloading the page.

Copy link
Contributor Author

@AddisonDunn AddisonDunn Apr 25, 2024

Choose a reason for hiding this comment

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

I kind of accepted that as a defect--if role's name is changed in a role's model that isn't updated in other modals, either. Generally I think that's true for other modal data. I had trouble figuring out a reasonable high-level change for that.

Copy link
Contributor

Choose a reason for hiding this comment

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

The js already rewraps the saved role with the data sent back from the server. I think you'd need to rewrap the other roles and/or recreate the RolesViewModel based on the new data.

That said, I checked out the branch and played around with the interaction, and I think it's fine to call that out of scope.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, that makes sense. Also maybe I could create a new array on each model that points to the self.permissions.access_all_locations observables on other models?

But yeah, was also thinking it might be out of scope here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wouldn't think you'd need to add any data - each role has the proper info about the other roles on page load, that data just isn't getting refreshed properly somewhere.

But yeah, out of scope is fine too.

…ocation-restricted-roles-assigning-unrestricted
@AddisonDunn
Copy link
Contributor Author

AddisonDunn commented May 8, 2024

@orangejenny it's been 2 weeks so merged in master. Could you give final thumbs up? (we are trying to merge today)

@AddisonDunn
Copy link
Contributor Author

Thanks!

@AddisonDunn AddisonDunn merged commit eaedf42 into master May 8, 2024
12 checks passed
@AddisonDunn AddisonDunn deleted the ad/warn-location-restricted-roles-assigning-unrestricted branch May 8, 2024 16:11
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.

2 participants