bckohan
commented
1 month ago The other issue that should be thought through here is how should status/network relationship drive indexing? Having a former status and a former network is redundant but its much more natural for the code to close an index when the status enum changes to former than when a network relationship changes
Depending on the use case there is some redundancy in concerns between the sitelog status field and the network relationship. For example, IGS has a "Proposed" network and sitelogs also go through the PROPOSED state in the station lifecycle. Does this need some rethinking?
The status field should be universally applicable across all use cases and networks exist to allow different deployments of the SLM to enable whatever grouping behavior they wish in UIs and data products. This also pertains to multi-tenant support #106
The problem here is that the status field is trying to be too many things. Right now it is doing double duty as a "meta data status" field and a "lifecycle status" field as pertains to IGS specifically.
There is actually a question here of whether the status field is necessary at all on the core data model. It could purely be used as an edit status field and everything else pushed into the network relationships. Default networks on creation, etc could then be configured in settings by deploying orgs informed by their individual use cases.
This would not be a major deal but it leads to weird filter UI bits like this: