Fields that are related to this part of the spec, https://wbcsd.github.io/tr/2023/data-exchange-protocol-20231207/#dt-carbonfootprint-scope, are not implemented correctly. The schema needs to be adjusted to include them as possible options, according to the requirements docs, as well as adjustments made on the database end as well. along with then ensuring that None fields are not rendered by the api, and example of this can be seen in the code somewhere.
[x] add remaining scope related fields to carbon footprint schema
[x] add remaining scope related fields to carbon footprint database model
[ ] ensure that None valued fields are not rendered by the API
An interesting thought here is that I think this is a good issue to start the introduction of the business domain model layer, as this issue of deciding whether something is global, regional etc, does not belong anywhere else, and it's better to represent such core logic without it being tightly bound to a technology such as Pydantic or SQLAlchemy
Fields that are related to this part of the spec, https://wbcsd.github.io/tr/2023/data-exchange-protocol-20231207/#dt-carbonfootprint-scope, are not implemented correctly. The schema needs to be adjusted to include them as possible options, according to the requirements docs, as well as adjustments made on the database end as well. along with then ensuring that None fields are not rendered by the api, and example of this can be seen in the code somewhere.
An interesting thought here is that I think this is a good issue to start the introduction of the business domain model layer, as this issue of deciding whether something is global, regional etc, does not belong anywhere else, and it's better to represent such core logic without it being tightly bound to a technology such as Pydantic or SQLAlchemy