minispike: As a developer, I want to build out a minimal data model supporting the reporting app configuration, so I can prove its effectiveness

[pbastia]

Description:

This card is to try out the data architecture discussed during the whiteboarding sessions. The goal is to:

• verify effectiveness
• identify pain points
• Create more implementation cards to bring it to a production standard

Work is in the Whiteboarding_2024_04_12 miro board, with the most relevant pieces tagged

The idea is to collaborate, as a team of 2 or 3, on building out those tables and a quick and dirty approach to generating forms dynamically based on configurations.

For the fontend generation piece, the wireframes (link and below) can be used as a model for the form organization

Acceptance Criteria:

Given I am a developer When I want to display the forms for a report Then I have a data model allowing me to find all the forms and the configuration

Given I am a developer When I want to display the forms for a report Then I have logic allowing me to transform a program configuration into that year's forms

Given I am a developer When I want to display the forms for a report Then the patterns and best practices are documented And painpoints and difficulties are identified and mitigated

Development Checklist:

• [x] Missing data tables (activity, source typers, gas, methods, fuels) (see https://github.com/bcgov/cas-reporting/issues/189)
• [x] Mock data entries for above tables
• [x] Configuration and configuration items tables
• [ ] Evaluation of configuration lookup performance?
• [x] Field/component mapping (Frontend? Backend? JSON? TBD)
• [x] Generation of flat, small JSON schemas for the individual form pieces
• [x] Rendering of mock forms without styling
• [ ] 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 by
• Blocking

[pbastia]

@patriciarussellCAS we can hopefully unlock a bunch of work by doing this early this sprint

[patriciarussellCAS]

Tagging @joshgamache and @BallardRobinett - can you please review this ticket and provide any feedback. If there are no issues or questions, then we can remove the backlog refinement tag. Thanks!!

[joshgamache]

@patriciarussellCAS

can you please review this ticket and provide any feedback. If there are no issues or questions, then we can remove the backlog refinement tag. Thanks!!

Reviewed ✔️. I didn't identify any missing details and think this is clear to execute on!

[patriciarussellCAS]

Tagging @dleard - with Pierre gone, do you have any updates on the status of this ticket?

[dleard]

Haven't had time to pick this up at all yet, but I synced with Pierre on Friday on this & he left me some notes on what's been done / where to go next. I hope to make some progress on it this week if time allows