Reg\Operator Admins & Access Requests - Internal User no longer approving new operator admins

[zoeyli-46]

Description:

IRC is no longer approving the creation of a new operator, or the new operators admins.
IRC is no longer approving or declining Operator Information for an operator when they sign up

Blocked by: #2160

Acceptance Criteria:

• Remove the approve and decline button from the Operator Information section of the Operator Administrators and Access Requests page
• Remove the approve and decline button from the Admin (previously "User") Information section of the Operator Administrators and Access Requests page, only if it is the creation of a new operator. (Note from BC: create_operator_and_user_operator auto-approves the admin associated with an operator, so we're status for this check instead of the is_new flag)
• Replace the approved status to "admin access" Figma => Sepehr: This has already been implemented in ticket Admin\User and Access Requests - Internal User can view access requests #2160
• correct roles can access this feature: Miro Board "BCIERS User Roles"

Given that I am an internal admin,
When a new operator is created for the first time,
Then I do not have an approve or decline button for their Operator Information or their Admin Information (in registration 1 admin was named "user information"

Given that I am an internal admin,
When a user tries to sign into an operator that already has an admin
Then I do have an approve or decline button for their Admin Information section

Figma for If the operator already has an admin,
Figma for if the operator is signing up for the first time, (new operator, no existing admin)

What is different here from Registration 1:
Removed “approve and decline” for operator information
Remove “new operator flag”, 'approved" status is replaced with "admin access"
Internal user does not approve of the creation of a new operator, or the admin of a new operator
Renamed User Information to Admin information
In the back end, flag the operator as approved.

Development Checklist:

• Create the page.tsx's needed in both cas_admin and cas_analyst. Much of the approval workflow existed in reg1 so can copy/paste over the structure (e.g. apps/registration1/app/(authenticated)/idir/cas_analyst/dashboard/operators/page.tsx)
• Create the React components. Again, can pull over a bunch from reg1 but they'll be different, so make copies in the admin components rather than making shared libs ones
• When a new operator is created, its status should default to Statuses.APPROVED and is_new = False => Sepehr: only is_new=False needs to be implemented, rest is in place (in UserOperatorServiceV2.create_operator_and_user_operator)
• When a new user_operator record is created for a new operator, its status should be Statuses.APPROVED => Sepehr: This is in place (in UserOperatorServiceV2.create_operator_and_user_operator)
• Remove the approval buttons as described in the AC on the FE
• rename User Information to Admin information
• In the FE, show "admin access" in the grid if the user_operator status is Statuses.APPROVED
• When a new user requests access to an existing operator, their status should should be Statuses.PENDING, and internal users need to see the Approve button. Only cas_analyst and cas_director can approve. Could implement user conditionality by: fetch the role in the grid component, or pass the role_name (we know what it is from the file structure) as a prop in page.tsx
• 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:

[zoeyli-46]

Hey @patriciarussellCAS @patrickisaac , @BCerki and I were chatting about how we may want to drag this to next sprint backlog since its part of the critical path and related to ticket #2160

[andrea-williams]

@zoeyli-46 question about this AC:

Given that I am an internal admin,
When a user tries to sign into an operator that already has an admin
Then I do have an approve or decline button for their Admin Information section

this is not what I was expecting to see. It was my understanding that the business area only wants to have to approve the first admin for an existing operator - if the operator already has an admin, that external admin should be approving or declining subsequent user requests. Is this still the case?

CC: @patriciarussellCAS @Sepehr-Sobhani

[patriciarussellCAS]

I agree with your assessment @andrea-williams - there should not be an approve or decline button in this case. That's for catching that!

[andrea-williams]

I agree with your assessment @andrea-williams - there should not be an approve or decline button in this case. That's for catching that!

'twas actually Inspector Sobhani who caught it!

[BCerki]

The best way to test this is to login as an industry user (bc_cas_dev_secondary or three) and request access to an operator (NOT Operator 1 Legal Name, New Operator 3 Legal Name, Existing Operator 4 Legal Name, New Operator 5 Legal Name; these are set up for the reg1 workflow). Then logout and come back in as an internal user, and try to approve/decline the request you made as an industry user.

[patriciarussellCAS]

Hey @BCerki I just tried the steps you recommended using bc-cas-dev-three, getting access to New Operation 9. I'm not totally sure if it's working correctly.
As an internal user, I can click on the pending access request and still have accept/deny buttons.

Then it asks if I want to accept "prime admin access" (which I think is outdated terminology right?) and then if I click yes, I get this error message:

[BCerki]

Hey @BCerki I just tried the steps you recommended using bc-cas-dev-three, getting access to New Operation 9. I'm not totally sure if it's working correctly. As an internal user, I can click on the pending access request and still have accept/deny buttons.

It's correct that you see the accept/deny buttons in the Admin Information section. Where you shouldn't see them is the Operator Information section.

Then it asks if I want to accept "prime admin access" (which I think is outdated terminology right?)

I don't know about the terminology on this, @zoeyli-46 , do you? I don't see the modal in the wireframes.

and then if I click yes, I get this error message:

Investigating, will update the ticket when I have more info This is a mock data problem. I'll fix it, but in the meantime, if you check with User 7/Existing Operator 6 Legal Name, you should be able to approve/deny.

I don't consider any of this a release-blocker

[zoeyli-46]

It's correct that you see the accept/deny buttons in the Admin Information section. Where you shouldn't see them is the Operator Information section.

@BCerki But they won't see the accept/deny buttons in the Admin Information section, if the industry user created a new operator, right? (i.e., did not select one in the select operator)

[BCerki]

It's correct that you see the accept/deny buttons in the Admin Information section. Where you shouldn't see them is the Operator Information section.

@BCerki But they won't see the accept/deny buttons in the Admin Information section, if the industry user created a new operator, right? (i.e., did not select one in the select operator)

Yes, if it's a new operator, there shouldn't be buttons. "New Operator 9 Legal Name" is confusingly named; it's not actually a new operator in the database. We've got a card for fixing confusing mock data! #2627

[zoeyli-46]

Then it asks if I want to accept "prime admin access" (which I think is outdated terminology right?)

@patriciarussellCAS @BCerki Tiegan says they would like this term to be replace with "Account Administrator". However, since its internal users only, its fine if its not updated.