Reg\Operation and Facility - Internal User can issue a BORO ID

zoeyli-46 commented 2 months ago

Blocked by #1702

Description BORO IDs are auto-generated by the system, but must be issued by an internal user BCGHGIDs are pre-populated from the SWRS import, but can be issued by an internal user if no SWRS data existed for it

An External User cannot edit their BORO ID or BCGHG ID. They can only see it in view-only mode.

Acceptance Criteria:

Given I am an Internal User, When I am on the Operation Information Page Then I can see the BORO ID field Figma

If no BORO ID then there is a button that says "Issue BORO ID"

Given that I clicked the button, the following things appear
the BORO ID
"BORO ID has been issued"

Undo functionality is dealt with in ticket #2396

Given I am an External User When I am on my Operation Information Page Then I see a read-only, and non-editable field for BORO ID and BCGHGID Figma

NOTE: EIOs don't get BORO ID, only BCGHGID, EIOs don't have facilities

Development Checklist:

[x] Add a new button or widget to the Operation Information page that is only visible to internal users.
[x] Show this button if:
- The operation does not already have a BORO ID.
- The operation is not of EIOs type.
- The operation does not have Registered status. (@andrea-williams to confirm this). Andrea's edit: internal users should only have the option to assign a BORO ID if the operation's status IS "Registered"
[x] Display a snackbar message when a BORO ID is issued.
[x] Create an endpoint accessible only to approved internal users, which will generate a BORO ID for the operation when called.
[x] Reuse the generate_unique_boro_id model method to generate the BORO ID for the operation.
[x] Ensure that in the endpoint:
- The operation is not of type EIO
- The operation has the Registered status
[ ] Write tests for the endpoint and the frontend part.

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

andrea-williams commented 2 months ago

going to split this out into 2 separate tickets - since we haven't generated BCGHGIDs before, there's quite a bit more work involved than for the BORO ID

BCGHGID split out into #2152

andrea-williams commented 3 weeks ago

@zoeyli-46 we noticed that there's an "Undo" button for issuing a BORO ID. This would be equivalent to cancelling a BORO ID, which last I heard, the business area hasn't yet fully decided what they want the process to be for doing that? There might be implications for notifying Ministry of Finance when a BORO ID is no longer valid that we're not aware of...?

My recommendation is to remove the "Undo" button from this ticket and split it out into a separate ticket for later. If you think it's best Zoey, we could add an extra step where the user has to click again to confirm they want to issue a BORO ID, since we're removing the ability to undo the ID?

cc: @patriciarussellCAS & @patrickisaac

zoeyli-46 commented 3 weeks ago

That's a great point Andrea. I was thinking the undo would be used "immediately" in case of accidentally issuing it, instead of "cancelling a BORO ID"? RE: confirmation extra step, Tiegan says that everyone got a BORO ID last time, so I feel like it would be annoying for the internal user if they have to click 2 buttons every time they want to issue a BORO ID when it is the primary path. In almost all cases, they would be issuing it, so it would be annoying since clicking "undo" would actually be more of an edge case. so I was thinking the undo would be less of a cancelling BORO ID, but used only if they accidentally clicked issue a BORO ID, then they can undo that.

patriciarussellCAS commented 3 weeks ago

My thoughts: If the internal user only sees the "Issue a BORO ID" button for regulated operations then technically they shouldn't give a BORO ID by accident. What I mean is, because regulated operations, new entrants and opt-ins MUST be given a BORO ID, if the system only shows the BORO ID button for those registration purposes, it wouldn't be by accident.

Maybe there is some other scenario that I'm not thinking about where they need to remove the assigned BORO ID right away, but I can't think of one.

[It's a whole separate issue if someone registered incorrectly and was not supposed to be regulated, in which case they were incorrectly assigned a BORO ID. But the chances of that happening are slim, given that Internal users will review the operation information, confirm the products they have listed, etc. before issuing the BORO ID]

zoeyli-46 commented 2 weeks ago

I created a separate undo ticket here #2396

patrickisaac commented 2 weeks ago

Refinement notes:

Dev checklist still required. (Sepehr to add them)

BCerki commented 2 weeks ago

@zoeyli-46, I've got a few questions on this one:

If a BORO ID hasn't been assigned yet, what does the external user see for the field? For now I put "N/A" to match the grid
If the BORO ID can't be assigned yet or at all (e.g. EIO, a operation doesn't have the registered status), what does the internal user see?
If there's an error with the generation, what should the user see? I did this for now: https://www.loom.com/share/fce2ef1ccca64085adf0f52d1c4b060a. These would API errors, like a connection was lost, or a user tried to put something into the db that isn't allowed

zoeyli-46 commented 2 weeks ago

If a BORO ID hasn't been assigned yet, "N/A" on the grid makes sense. What if when no BORO ID or BCGHGID has been issued that those fields just don't show up on their operation information form? its hidden until one is issued?

If the BORO ID can't be assigned yet or at all (e.g. EIO, a operation doesn't have the registered status), I think the internal user should see 2 different messages in place of the button.

[ ] Cannot be issued yet. Operation is not registered. (i.e., for operations not yet registered)
[ ] Not applicable (i.e., for EIOs)

Is the only kind of error for the ID generation related to the operation not being registered? If its to do with the operation not being registered, then we should show the message in my bullet above, in place of the button. That way they don't have to try clicking on the button first only for it to fail.

BCerki commented 2 weeks ago

If a BORO ID hasn't been assigned yet, "N/A" on the grid makes sense. What if when no BORO ID or BCGHGID has been issued that those fields just don't show up on their operation information form? its hidden until one is issued?

If the BORO ID can't be assigned yet or at all (e.g. EIO, a operation doesn't have the registered status), I think the internal user should see 2 different messages in place of the button.

[ ] Cannot be issued yet. Operation is not registered. (i.e., for operations not yet registered)

[ ] Not applicable (i.e., for EIOs)

Is the only kind of error for the ID generation related to the operation not being registered? If its to do with the operation not being registered, then we should show the message in my bullet above, in place of the button. That way they don't have to try clicking on the button first only for it to fail.

Hiding the fields is a lot more complicated than showing a blank/N/A/some other placeholder. Messages instead of a button sounds good. There are many types of errors, e.g. something went wrong with their connection, we have some sort of db rule that they're breaking, etc.

zoeyli-46 commented 2 weeks ago

in that case, for external users they can just see the same messages as internal user Cannot be issued yet. Operation is not registered. (i.e., for operations not yet registered) Not applicable (i.e., for EIOs)?

BCerki commented 2 weeks ago

Yup! If it's just that one hasn't been assigned yet (it's not an EIO, it is registered, just no internal user has pressed the button), then what?

zoeyli-46 commented 2 weeks ago

"Not issued yet"? :)

patriciarussellCAS commented 2 weeks ago

I was going to say "pending" for those who require a BORO ID but don't have one yet, but "not issued yet" works as well. I don't think using "N/A" makes sense because it means "not applicable" and it is applicable for regulated operations, they just don't have one yet. Would users who don't require a BORO ID [EIOs, reporting operations and potential reporting operations] see that field in the Operation Info form with the N/A? Or is it hidden for them? I guess the same question applies for internal users - do they only see the BORO ID field if they are looking at the operation info page for a Regulated, Opt-in or New Entrant operation?

zoeyli-46 commented 2 weeks ago

Those who dont require a BORO ID would still see it, same with internal user side. Brianna says hiding fields is much more complex than just showing a message. @patriciarussellCAS

Also, I like "Pending" better as well. Can we put that as the status in the grid too then instead of "N/a"? @BCerki

BCerki commented 2 weeks ago

Brianna says hiding fields is much more complex than just showing a message.

Yes--a message is one line of code, hiding is more, but it is doable if it's important.

Would users who don't require a BORO ID [EIOs, reporting operations and potential reporting operations]

This ticket AC only talks about EIOs not requiring a BORO ID. Are there other purposes that shouldn't have it? @patriciarussellCAS

I can use "Pending" on the form as part of this ticket. We can change it in the grid but it's more than a one-liner (unless it's just "N/A" to "Pending", no conditions or special cases), so I'll make another ticket to keep the scope of this one the same. https://github.com/orgs/bcgov/projects/123/views/16?pane=issue&itemId=84738604&issue=bcgov%7Ccas-registration%7C2414 @zoeyli-46

bcgov / cas-registration

Reg\Operation and Facility - Internal User can issue a BORO ID #2141