Reg\Register an Operation\Page "Registration Purpose"- External user can register the operation

[zoeyli-46]

Description:

As an industry user, given that the operation has been added to my operator, I can register the operation for IRC approval.

Acceptance Criteria:

Given that I am on the Operations grid and clicked Add and Register an Operation, or if I am on the Registration dashboard (or main BCIERS dashboard) and clicked Register an Operation, Then I am brought to the first page of the Register an Operation form: the Operation Information page https://www.figma.com/design/LsDmLDCdnJqI8UahyqvOD8/BCIERS-Designs?node-id=10222-8&t=rBpJCzhxRzIMrjwm-4

Given that I opened the dropdown menu, The options are presented in the following order:

• [x] Reporting Operation
• [x] OBPS Regulated Operation
• [ ] Opted-in Operation
• [x] New Entrant Operation
• [ ] Electricity Import Operation
• [x] Potential Reporting Operation

Restrictions User can only pick 1 option

• [x] all options EXCEPT “potential reporting operation” should automatically mark the user as a “reporting operation” in the back end.
• [x] if the user picks new entrant or opt in, (new AC) Reporting Operation, or OBPS Regulated Operation, mark the user as a Reporting AND regulated operation in the back end.

Given that I select the Regulated Operation, Reporting Operation, New Entrant or Opt-in as the registration category Then the page shows the form field for Regulated products

~Given that I select opt in or new entrant, then an extra bubble appears in the stepper as step 4, after facility information~ pulled out into tickets #1906 and #1952

Development Checklist:

• [x] Create new enum class RegistrationCategory with options: 'Potential Reporting Operation', 'Reporting Operation', 'Regulated Operation', 'Opt-in Operation', 'New Entrant Operation', 'Electricity Import Operation'

• [x] modify Operation model to add a one-to-many relationship between an operation and registration categories (operations can have multiple registration categories, although for usability purposes on the front-end external users will only be able to select one category, the other applicable ones will be automatically applied)

• [x] re-introduce regulated_products for operations (this work was partially completed during Registration Part 1 and was then commented out; some additional work may still need to be done). There should be a many-to-many relationship between regulated_product and operation

• [x] each step of the Registration workflow form should hit a different API endpoint

• [ ] 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:

Dependencies

• Blocked
• Blocking #1952 , #1906

[BCerki]

@andrea-williams , in 1952 the registration purpose and operation are many-to-many; in this ticket it's one-to-many. Thoughts? I've done it as one-to-many in https://github.com/bcgov/cas-registration/pull/1990/files but I think many-to-many might actually make more sense

[BCerki]

@andrea-williams , in 1952 the registration purpose and operation are many-to-many; in this ticket it's one-to-many. Thoughts? I've done it as one-to-many in https://github.com/bcgov/cas-registration/pull/1990/files but I think many-to-many might make more sense

@andrea-williams is on vacation! @Sepehr-Sobhani , thoughts?

[Sepehr-Sobhani]

I reviewed the PR for this ticket and I believe your implementation is correct. With this approach, each operation can have multiple purposes, and we can query all purposes of an operation using the related_name. Another way to implement this would be to have a ManyToMany field in the RegistrationPurpose data model, but on the front end, we only allow for one option to choose from. This approach eliminates the need to use TimeStampedModel for the RegistrationPurpose data model.

[shon-button]

@patriciarussellCAS

Note: 'Register an Operation` a multi-step process, reachable at: https://cas-bciers-frontend-dev.apps.silver.devops.gov.bc.ca/registration/register-an-operation

[patriciarussellCAS]

Review Note:

• Works in Dev. Have not reviewed in Test.
• Noting the nav bar still has "New Entrant Application" as step 3 but this is being addressed in another ticket.
• Future work may be required to address the "registration purpose" discussions but I'll close this ticket and address that in later work. thanks!