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

Admin\User and Access Requests - Internal User can view access requests #2160

Closed
5 of 22 tasks
shon-button opened this issue Sep 5, 2024 · 3 comments
Closed
5 of 22 tasks
Assignees

Comments

@shon-button
Copy link
Contributor

shon-button commented Sep 5, 2024

Dependencies

Description:

As an internal user, I can see Operator Administrators and Access Requests grid(Only admin requests). This ticket is just about creating the grid. Actually approving/rejecting requests is in 2059

Acceptance Criteria:

Given I am an internal user on the dashboard
When I click Operator Administrators and Access Requests
Then I am brought to the Operator Access requests grid

Development Checklist:

  • Create a page for the grid (start with a copy/paste of reg1's apps/registration1/app/(authenticated)/idir/cas_admin/dashboard/operators/page.tsx) into both cas_admin and cas_analyst
  • Update the grid to match the reg2 wirename (notably the statuses, confirm columns etc. too)
  • To get the data for the grid, create v2 version of @router.get("/user-operators"...) and relevant services. Reg1 excludes certain user_operators and for reg2 they should all be visible
  • vitests (can probably straight copy/paste from reg1)
  • pytests
  • Meets the DOD

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

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

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

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

Notes:

@patrickisaac
Copy link

Refinement Notes:

  • Revisit AC and include DevChecklist

@Sepehr-Sobhani
Copy link
Contributor

Hey @zoeyli-46 / @andrea-williams!
In Reg1, we excluded admin requests based on the following conditions:

  • Pending user_operators belonging to operators that already have approved admins
  • Approved user_operators that were approved by industry users

Which of these two conditions still apply in Reg2?

@vesselak
Copy link

Tested in dev. Operation Access Grid is visible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants