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

Display success banner when adding or removing access to an application #3171

Closed
wants to merge 2 commits into from

Conversation

Gweaton
Copy link
Contributor

@Gweaton Gweaton commented Sep 17, 2024

Trello card

Changes in this PR

We previously displayed a success alert banner when one's own or another user's permissions were updated, but didn't show anything when granting access or removing it. We now display the same banner with different messaging when a user's access is granted or removed.

This was a little more involved than I'd expected due to the challenge in differentiating cleanly between a user having all their permissions removed and seeing one message (i.e. they just have the "Signin" permission) and a user being granted access to an app (i.e. also just having the "Signin" permission) and seeing another message in the banner. Because of this, I've had to make use of some additional flash variables and flags to method arguments.

The API Users journey didn't need updating here, as we already show flash messages when an API token is created or revoked, as well as when permissions are updated.

Screenshots

Granting own access

image

Removing own access

image

Granting another user access

image

Removing another user's access

image

This application is owned by the publishing platform team. Please let us know in #govuk-publishing-platform when you raise any PRs.

⚠️ This repo is Continuously Deployed: make sure you follow the guidance ⚠️

Follow these steps if you are doing a Rails upgrade.

@Gweaton Gweaton force-pushed the add-success-banner branch 2 times, most recently from 6128128 to cb7ddb2 Compare September 17, 2024 08:28
This was a lot more complex than I'd hoped due to the difficulties in
cleanly distinguishing between a user having the Signin permission
granted vs having all permissions other than the Signin permission
removed.

I hope this is reasonably clear and duplication-free. I'd rather have
avoided passing the `granting_access` flag if possible and opting for
something slightly more extendable in future, but it won out over the
following alternative approaches:

1. Performing a lot of this logic in the view - harder to test, a bit
   too much duplication and adding too much logic to a rendering
   template.
2. Refactoring the `ApplicationPermissionsHelper` to support a new path
   for granting access - this had a lot of fairly complex branching
   logic in it and felt fairly geared towards "permissions" rather than
   "access" so I've opted against extending it further.

I've opted against writing controller tests for this behaviour. Although
we have some where we test for the presence of `flash[:application_id]`,
this feels a bit over the top, and I think it's sufficiently covered
with integration tests that are testing the view.
This takes a similar approach to the previous banner. However, I've had
to perform a little more logic in the view here to allow us to re-use
the success alert component.
Copy link
Member

@yndajas yndajas left a comment

Choose a reason for hiding this comment

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

Looks good. Just a few suggestions, the main one being about the distinction between methods in the success alert helper

else
{
message: "Permissions updated",
description: message_for_success(application_id, user),
Copy link
Member

Choose a reason for hiding this comment

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

Could we possibly change the name of message_for_success to something like permissions_updated_message to make this more readable without much context (and more in line with the better name you chose: access_granted_message)?

Comment on lines +16 to +21
def access_removed_params(application_id, user: current_user)
{
message: "Access removed",
description: access_removed_message(application_id, user),
}
end
Copy link
Member

@yndajas yndajas Sep 17, 2024

Choose a reason for hiding this comment

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

I'm not sure I see the distinction between the two methods in this file. The first one includes granted in the name but it would also apply if permissions have been removed (or even some granted, some removed), so I'm not sure the granted/removed distinction holds?

Could the method added in the previous commit maybe be rejigged here to accommodate the three options (e.g. adding removing_access: to the method signature), or a clearer distinction made? This would extend the conditional logic in the helper a little but allow the view to stay 'simple'

end

context "when the user is granting another access" do
should "return a message informing them that the other user have access to an application" do
Copy link
Member

Choose a reason for hiding this comment

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

have access -> has access

@@ -29,6 +29,9 @@ def assert_grant_access(application, grantee, grantee_is_self: false)

assert app_with_access_table.has_content?(application.name)
assert grantee.has_access_to?(application)
success_banner_caption = grantee_is_self ? "You have been granted access to #{application.name}." : "#{grantee.name} has been granted access to #{application.name}."
Copy link
Member

Choose a reason for hiding this comment

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

Looks like _caption was copied from table_caption? That's referring to the table caption option. I guess this should be _description (to match the actual option) or just _body?

Likewise in test/support/removing_access_helpers.rb in the next commit


context "#access_removed_message" do
context "when the user is removing their own access" do
should "return a message informing them that they have access to an application" do
Copy link
Member

Choose a reason for hiding this comment

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

The should descriptions need updating for this method

@Gweaton
Copy link
Contributor Author

Gweaton commented Sep 18, 2024

Closing in favour of #3175

@Gweaton Gweaton closed this Sep 18, 2024
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