1553 configuration data model

[pbastia]

Spike project for bcgov/cas-reporting#250

Wrap up

This is a proof of concept to investigate the validitiy of the solution. Much of the code in this PR is "just make it work" code & needs to be improved upon. The POC has found that this is a viable solution for dynamically creating forms from a configuration that should be easy to maintain and handle change gracefully.

Models:

• reporting_source_type
• reporting_gas_type
• reporting_methodology
• configuration
• configuration_element
• reporting_field
• The above models were created in this POC branch. An extra model was created (config_element_reporting_field) that shouldn't need to be created manually as Django will create that many-to-many intersection table if we mark a ManyToMany reporting_field column in the configuration_element model
• A couple models not created in the POC that we will need for the actual implementation are:
  • base_schema: this should contain the non-conditional schema for an activity-sourcetype pair (non-conditional meaning that the layout of the form is fairly static as it does not depend on gastype or methodology selections). Attributes:
    • schema (json)
    • slug (i.e. "general-stationary-combustion_2024" "alumina-production_anode-consumption_2024" etc.)
  • source_type_schema: this is a table to connect and version the base schema to the activity-sourcetype pair and should have the following attributes:
    • activity_id
    • source_type_id
    • base_schema_id
    • valid_from
    • valid_to

API:

• We'll need to create a a /reporting api router
• The service functions in report_config_service.py can be used as a starting point, but the queries could probably be done more efficiently
• The schema definition / generation was done in the front end for the POC, but should be done via an API endpoint/service that generates the schema and passes it to the frontend

Front End:

• In this POC, there is one client component. We will probably need two client components. One to do the data fetching from the API & store state and a second client component to render the form & bubble up the results of selections (for example, when selecting a methodology, bubble that selection up to the parent, fetch the reporting_fields, generate the new schema & pass that down as props to the form component)
• The POC was done in an unauthenticated route for ease of development, this route should be gated behind the bceid dashboard

Unanswered questions

• How to handle the UI schema? (ie: where to store it, how/if to version it)

[pbastia]

@dleard here's where I am at:

• The data tables including the configuration tables are created
• The sample data and sample configuration data are in a migration called 0005_sample_configuration_data. It relies on the ReportingActivity model as well

Next steps as I see it:

• create a python service with one method that generates the JSON schema for a single emissions report form
• create an API endpoint that calls this service and that can be called by the frontend
• create a frontend page that calls the API for the JSON schema (or a collection)
• create an RJSF component that renders that form

cc @patriciarussellCAS for progress. See "Whiteboarding_2024_04_12" miro board for diagrams

[dleard]

Current state:

• Added an API route for reporting
• POC endpoint & service that fetches the config & prints out each by activity, source_type, gas_type & methodology
• Created a reporting_fields model that connects fields to a configuration_element record
• Prints fields by config element

Next:

• (maybe) add a base_schema model that contains versioned records of the schema for each activeity - source type pair that is static based on those 2 items (ie: in GSC: everything up to 'gas_type')
• Create a basic POC rjsf on the frontend that is dynamically generated by the configuration_element <-> reporting_field relationship