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

#3943 - Bug - restriction view when access limited #3982

Merged
merged 2 commits into from
Nov 22, 2024

Conversation

lewischen-aot
Copy link
Collaborator

@lewischen-aot lewischen-aot commented Nov 21, 2024

  • Removed the check-role-permission decorator to allow ministry users without designated roles to close the modal as per AC
    • The 'Close' button is not disabled for all users. Users without restriction edit access should be able to view it, not edit it and then close the modal without refreshing.

Screenshot
image

@lewischen-aot lewischen-aot added Bug Something isn't working Security-related Issues related to security Web portal Usability labels Nov 21, 2024
@lewischen-aot lewischen-aot self-assigned this Nov 21, 2024
@lewischen-aot lewischen-aot marked this pull request as ready for review November 21, 2024 22:02
@@ -160,6 +153,8 @@ export default defineComponent({
return "Resolution reason is required.";
};

console.info("props.canResolveRestriction: ", props.canResolveRestriction);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please remove the console.info.

/>
</template>
</check-permission-role>
<footer-buttons
Copy link
Collaborator

Choose a reason for hiding this comment

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

Check permission role is required and must not be removed.

</check-permission-role>
<footer-buttons
:processing="processing"
:primaryLabel="allowUserToEdit ? 'Resolve restriction' : 'Close'"
Copy link
Collaborator

@dheepak-aot dheepak-aot Nov 21, 2024

Choose a reason for hiding this comment

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

I would suggest the following quick solution which would keep the primary behavior as primary and secondary behaviour as secondary not having to juggle based on the situation.

Solution

<template #footer>
        <check-permission-role :role="allowedRole">
          <template #="{ notAllowed }">
            <footer-buttons
              primaryLabel="Resolve restriction"
              :secondaryLabel="allowUserToEdit ? 'Cancel' : 'Close'"
              @primaryClick="submit"
              @secondaryClick="cancel"
              :disablePrimaryButton="notAllowed"
              :showPrimaryButton="allowUserToEdit"
            />
          </template>
        </check-permission-role>
      </template>

Note: there is no processing variable so removed :processing="processing"

Result:

View Active Restriction with permission

image

View resolved restriction with permission

image

View Resolved restriction without permission

image

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The solution looks great, and we can probably adopt this in other stories. Thanks @dheepak-aot

secondaryLabel="Cancel"
@primaryClick="allowUserToEdit ? submit() : cancel()"
@secondaryClick="cancel"
:showSecondaryButton="allowUserToEdit"
Copy link
Collaborator

@dheepak-aot dheepak-aot Nov 21, 2024

Choose a reason for hiding this comment

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

Or as a bare minimal solution. This will disable primary button only if the edit action is possible.

image

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree with this solution, which is adopted in the latest commit.

@dheepak-aot
Copy link
Collaborator

Please have a look at the comments.

Copy link

Backend Unit Tests Coverage Report

Totals Coverage
Statements: 22.09% ( 3718 / 16834 )
Methods: 10.19% ( 214 / 2101 )
Lines: 25.42% ( 3226 / 12689 )
Branches: 13.6% ( 278 / 2044 )

Copy link

E2E Workflow Workers Coverage Report

Totals Coverage
Statements: 65.43% ( 583 / 891 )
Methods: 59.26% ( 64 / 108 )
Lines: 68.54% ( 464 / 677 )
Branches: 51.89% ( 55 / 106 )

Copy link

E2E Queue Consumers Coverage Report

Totals Coverage
Statements: 86.93% ( 1244 / 1431 )
Methods: 88.57% ( 124 / 140 )
Lines: 87.78% ( 1056 / 1203 )
Branches: 72.73% ( 64 / 88 )

Copy link

E2E SIMS API Coverage Report

Totals Coverage
Statements: 66.94% ( 5774 / 8625 )
Methods: 64.8% ( 718 / 1108 )
Lines: 70.87% ( 4531 / 6393 )
Branches: 46.71% ( 525 / 1124 )

Copy link
Collaborator

@dheepak-aot dheepak-aot 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 @lewischen-aot 👍

@andrepestana-aot andrepestana-aot self-requested a review November 22, 2024 00:40
Copy link
Collaborator

@andrepestana-aot andrepestana-aot left a comment

Choose a reason for hiding this comment

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

👍

@lewischen-aot lewischen-aot deleted the bug/#3943-restriction-when-access-limited branch December 13, 2024 00:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working Security-related Issues related to security Usability Web portal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants