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

zoeyli-46 commented 2 months ago

Dependencies

Blocked by #1899
Blocking #1895

Description:

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

Acceptance Criteria:

Given I am on the first page of the registration form When I click on the Operation dropdown, Then the list of operations will only show operations that have been added but not yet registered (this dropdown was implemented in #1899 but it's not yet filtered on registration status)

Given that I selected an operation from the dropdown, Then the operation form of the selected operation will appear, so that I can review the information and be able to edit it

Given that I am on the operation information page of the New Registration form, When I click on the Add a New Operation button Then I can see an empty operation form in edit mode, so that I can fill it out

~Given that I selected EIO as my registration purpose Then I see fewer fields on the operation information form. I only see~

[ ] ~Operation name~
[ ] ~Operation type~
[ ] ~the multiple operators section~ ~EIO Form Figma link~ EIO user story has been separated into ticket #1962

Development Checklist:

[ ] each step of the form hits a different endpoint of the API
[ ] we can't put the add operation form as children of the multistepbase as-is because
within a creates a hydration error. We could move the buttons outside of the form in MultiStepBase and then add form refs. Or look at how it's done for operation representative

Changes to make to Operation data model:

[ ] naics_code field: no changes required to field, but add comment that the column refers to "primary naics code"
[ ] secondary_naics_code - add nullable field that is an FK to our naics codes table
[ ] tertiary_naics_code - same as secondary_naics_code
[x] add many-to-many relationship between Operation and Registration Category (see below)

Changes to make to document_type data model:

[ ] add record for new_entrant_application

Changes to make to bc_obps_regulated_operation data model:

[ ] add status field (required) which is an enum of either "Active" or "Inactive". All statuses should be "Active" by default

Create new enum class Registration Category:

[x] options: "Potential Reporting Operation", "Reporting Operation", "Regulated Operation", "Opt-in Operation", "New Entrant Operation", "Electricity Import Operation" (additional data fields specific to certain registration categories will be separated out into other tickets)

Changes to make to operation_ownership_timeline data model (repurposing this - it turns out we don't need to track ownership of an operation, but we do need to track who the "designated operator" of an operation is, which can change):

[ ] rename table to operation_operator_timeline (or if you can think of a better name, use that instead!)
[ ] update comments on model to reflect that the data is about the "designated"/controlling operator, who isn't necessarily the owner
[ ] fields in table are unchanged

Changes to make to facility_ownership_timeline data model (repurposing this - as with operations, we don't need to track facility ownership, but rather just what operation the facility belongs to, which can change over time):

[ ] rename table to facility_operation_timeline (or if you can think of a better name, use that instead!)
[ ] update comments on model to reflect that the data captures the relationship between the facility and operation it falls under, not facility ownership
[ ] fields in table are unchanged
[ ] 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 commented 2 months ago

Potential to be broken down into multiple user stories

BCerki commented 2 months ago

We'll need to figure out how to do the snapshot thing in the db

andrea-williams commented 2 months ago

Update AC based on pending decisions from business area

patrickisaac commented 1 month ago

Splitting into multiple stories by @zoeyli-46

shon-button commented 3 weeks ago

Deletion Candidate Reason:

Registration purpose and operation info steps have been combined into a single step

PR: https://github.com/bcgov/cas-registration/pull/1990 Ticket: https://github.com/orgs/bcgov/projects/122/views/2?filterQuery=&pane=issue&itemId=69561695

BCerki commented 3 weeks ago

Deletion Candidate Reason:

Registration purpose and operation info steps have been combined into a single step

PR: #1990 Ticket: https://github.com/orgs/bcgov/projects/122/views/2?filterQuery=&pane=issue&itemId=69561695

I think we still need this one. I was trying not to wildly expand the scope of the one I'm working on, so I'm only adding the 'select operation' part, not the add part.

BCerki commented 3 weeks ago

@zoeyli-46 and @shon-button I've updated this ticket

bcgov / cas-registration