Admin\Operator - External User can see operator's user access grid

zoeyli-46 commented 5 months ago

Description:

As an external user, I can see the users that have access to my operator

Acceptance Criteria:

Given I am on the dashboard When I click on users and access requests Then I am brought to the users and access requests grid Figma

Development Checklist:

[x] copy/paste over this feature and tests from reg1
[x] update any links that broke (might need to add dashboard in some places)

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[x] User story is included
[x] User role and type are identified
[x] Acceptance criteria are included
[x] Wireframes are included (if required)
[x] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[x] Story has been estimated (under 13 pts)

·Definition of Done (Note: If any of these points are not applicable, mark N/A)

[x] Acceptance criteria are tested by the CI pipeline
[x] UI meets accessibility requirements
[x] Configuration changes are documented, documentation and designs are updated
[x] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[x] Ticket is ready to be merged to main branch
[x] Can be demoed in Sprint Review
[x] Bugs or future work cards are identified and created
[x] Reviewed and approved by Product Owner

Notes:

Dependencies

Blocked by
Blocking

patriciarussellCAS commented 1 month ago

@zoeyli-46 could we update the Figma link to the correct wireframe. I'd like to refine and prep this ticket for next sprint. Thanks!

zoeyli-46 commented 1 month ago

Done!

Sepehr-Sobhani commented 1 month ago

Having a "Search" field to filter the table was not required for Reg part 1. Is it necessary for Reg part 2? Should we implement it now? cc: @patriciarussellCAS @andrea-williams

zoeyli-46 commented 1 month ago

If it will factor into the decision at all, I don't think search is necessary (I just have it included on every grid in the designs) because it's not likely that operators will have that many users that they need to search for a user.

If anything, the "sort" functionality is probably more important so that the user can "sort" the table so that they can see the requests at the top, unless we implement it in a way that by default requests show up at the top.

Sepehr-Sobhani commented 1 month ago

Sort functionality already implemented!

patriciarussellCAS commented 1 month ago

Thanks @Sepehr-Sobhani and @zoeyli-46 - this works as described. My only review note is that "BCeID Business" should actually be called "Business BCeID" (that's the official name, and how it's displayed on our main BCIERS log in page). Is it possible to make that minor change now before I approve?

I agree that we likely don't need a search function here but the ability to sort by columns will be sufficient.

Sepehr - can you confirm that all the relevant items in the DOD are complete?

Sepehr-Sobhani commented 1 month ago

Thanks @Sepehr-Sobhani and @zoeyli-46 - this works as described. My only review note is that "BCeID Business" should actually be called "Business BCeID" (that's the official name, and how it's displayed on our main BCIERS log in page). Is it possible to make that minor change now before I approve?

I agree that we likely don't need a search function here but the ability to sort by columns will be sufficient.

Sepehr - can you confirm that all the relevant items in the DOD are complete?

Since this feature is already in DEV, I have created a task ticket to cover that renaming tweak. Regarding the DOD, I've checked all the relevant ones except the one about QA because I'm unsure if it applies now.

bcgov / cas-registration