Reg\Select Registration Purpose

[andrea-williams]

Blocking #1962

Describe the task

We need to handle the scenario where an external user partially or fully submits an operation registration form, and then wants to change their selected registration purpose (RP), since this could impact the data associated with the registration.

The Reg Purpose may be changed in the multistep registration workflow (before the "Submit" button is clicked), or after submission, from the Operation Details page.

This requires writing a lot of backend manual logic to delete data when it becomes no longer relevant because the RP has changed.

Dev Checklist

• [ ] write functionality to delete data that is no longer relevant when the RP is changed
• [ ] make the RP dropdown in Operation details page editable
• [ ] create new UI component that warns user about pending data deletion (see Miro wireframe)
• [ ] requires extensive testing to ensure that only and all the correct data is deleted, and that no additional data is deleted that should be kept
• [x] make sure that if user selects "Reporting Operation" or "Potential Reporting Operation", the "OBPS Regulated Operation" purpose is NOT applied

Acceptance Criteria

• [ ] if an external user wants to change their registration purpose after they've saved (but not submitted) a Registration record, they are prompted to confirm that they want to change their RP, and the Registration record they had saved will be deleted (see wireframe for Reporting - Registration module should match this)
• [ ] if an external user wants to change their registration purpose after they've submitted (i.e., their operation is already registered, so they're editing from the Operation Details page), ensure that no longer relevant data fields are deleted from database. See Miro table for which fields would no longer be relevant

Additional context

• See Miro board: https://miro.com/app/board/uXjVN6uBj9Y=/?moveToWidget=3458764598469935002&cot=14
• and this board: https://miro.com/app/board/uXjVLUOERmg=/?share_link_id=931450344603

[shon-button]

AW:

Changing Registration Purpose for Moose and Russell, Patricia ENV:EX - I've been thinking a bit more about that dreaded topic, changing registration purpose. Here's our options as I see them:

(Easiest implementation) You can't change registration purpose. Specifically, the "Registration Purpose" field in the Edit Operation details page is non-editable, and in the multistep Registration form, once the user has submitted the first step of the form, they can't go back and change registration purpose. IMO we'll need to provide more help text than what we currently have in the wireframe, to help external users make sure they're selecting the correct registration purpose Some registration purposes can be changed. Some of the RPs are actually straightforward to change around, specifically "reporting", "regulated", and "potential reporting" don't have any differences in the data collected, so switching between them is easy. We could allow users to change amongst these RPs without creating any headaches for devs. It would only be Opt-ins, New Entrants, and EIOs that we'd have to forbid users from changing to/from. (probably the most user-friendly, but the most technically complex to implement) Users are permitted to change their selected registration purpose either after they've submitted their registration form (through the Edit Operation page) or by navigating back to the first step of the registration workflow (in cases where they haven't yet submitted their registration). Provides more grace room for external users to make mistakes, but is a lot more complex to implement. We'd have to perform data cleanup in some cases (e.g., deleting data fields that no longer apply to the new RP), and also have to conditionally render data fields in the Edit Operation page and enforce that missing data is provided before the user can submit their changes. for reference, I've created a table of how data would be impacted by changing RPs here

I think this is a topic we should bring to the biz area, and I think we need to make a decision on this pretty soon. Do you feel ready to talk about this with the biz area tomorrow? Or should we leave it until next Monday (or the following week?) Andrea's (brain) dumping ground A post on Miro provided by: https://miro.com

[patriciarussellCAS]

I'm moving this back into next sprint backlog so we can prioritize refinement and prep it for next sprint.

[andrea-williams]

Relevant notes from Registration Collab (Sept 17):

• RT: if an LFO were to change over to an SFO, they'd be expected to register a new operation rather than changing the LFO's operation type
• TL: any operation that has a BORO ID from Reg1 can be considered a regulated operation. Opt-ins shouldn't have a BCGHG ID or have reported before
• JM: if an EIO is accidentally created, it should be deleted
• reached consensus in meeting that it's ok that an external user will only be selecting one registration purpose from the dropdown when going through the registration workflow, but then multiple purposes will be displayed in the Operation Details page. For existing operations from Reg1, the operation type should not be editable.
• aim to mitigate potential errors with external users selecting incorrect registration purpose by adding help text for each option in the dropdown - this applies to newly created operations
• for operations from Reg1, the relevant registration purpose should be pre-selected and made non-editable; same for operation type

To Do:

• write new ticket to create data migration script for operations from Reg1 so that the applicable registration purpose is pre-selected for them and cannot be changed. If they already have a BORO ID, they're "OBPS Regulated". Operations from Reg1 marked as opt-ins should be set to a new registration purpose called "Previously Opted In" (these operations need to still be marked as opt-ins, but shouldn't be shown the opt-in form again).

[andrea-williams]

discussion with Patricia Oct 29: external users should be allowed to change their operation's registration purpose after registration (from the Operation Details page) in order to handle cases where the wrong RP has accidentally been selected