feat: editors can select which planning constraints to check

[jessicamcinchak]

Changes & testing notes:

• PlanningConstraints editor modal now allows you select/de-select datasets to check (you must select at least one)
  • The public component only fetches and displays the datsets that you've selected
  • The passport (property.constraints.planning & _nots["property.constraints.planning"]) only include data values for the datasets that you've selected
• Existing PlanningConstraints components fetch all datasets by default
• Validation check prevents you from publishing a flow with more than one PlanningConstraints component

Further context in Slack here https://opensystemslab.slack.com/archives/C5Q59R3HB/p1732703826935819

[jessicamcinchak]

Give 'Planning Constraints' component datasets a 'hide from user' toggle

[github-actions]

Removed vultr server and associated DNS entries

[DafyddLlyr]

Looking great! A few minor comments but no show stoppers 👍

[DafyddLlyr]

Maybe datasets is more meaningful here?

[DafyddLlyr]

Do we need a fallback way of handling "all" values?

dataValues?: string[] | "all"

If Planning Data add a new dataset, it would be pretty cumbersome to have to get all services to toggle it on. I think Editors would think that ticking the "main" checkbox means "all datasets" not just "all currently listed".

Alternatively if we could easily update all PlanningConstraints nodes with any new dataset this would also be solved.

[jessicamcinchak]

Feel quite strongly that datasets is NOT a good name because we're not allowing users to say "I only want to check TPO orders dataset from Planning Data, not TPO zones" - rather we're letting them select/deselect our pre-curated "options" (each with a title, passport value, and associated source datasets).

Perhaps options is more generic and easier to grasp here though? In my mind, they're basically the PlanningConstraint node's equivalent of Question/Checklist "edges"/"options" ?

[jessicamcinchak]

As for the "all" question - I think this becomes much simpler in a word of Templates (eg PlanningConstraints will not be a "placeholder" node therefore just updated once per service template & changes propagated to children on publish?), and if still too cumbersome then would favor data migration script like you say!

Also no near-future requests for more datasets from Planning Data besides Planning History which I think will have a strong argument for it's own component or API outside of existing /gis.

[DafyddLlyr]

It's tricky as these aren't 1:1 Planning.data datasets, but I think we should use a more meaningful param name here - maybe datasets, but this isn't ideal given the context here and the existing meaning datasets has.

We also need to add this new param to Swagger docs 👍

[jessicamcinchak]

Went with vals because the response includes a val property for each item - agree not most semantically meaningful though ! Continue to strongly oppose "datasets" though as that already corresponds to Planning Data source, not our curated constraint item which rely on one or many source datasets.

[jessicamcinchak]

In addition to updated unit tests here, logic changes have been thoroughly tested by content team with lots of notes in this thread: https://opensystemslab.slack.com/archives/C5Q59R3HB/p1732703826935819

Summary is:

• I've isolated planning constraints automation rules from larger automation rules in an attempt to have more clarity/flexibility around these - so constraints "rules" are now:
  • If there are intersecting constraints that exactly match the option, automate through that option
  • If there are no intersecting constraints that exactly match the option, but there is a "not" that exactly matches the option and a blank option available, automate through the blank
  • If there are no intersecting constraints or "nots" that exactly match an option (aka the option is something that we have not queried), put to user exactly once (future instances can be considered a "seen" option and therefore automated)
• (Extra credit bonus) Since planning constraints store all granularity levels in the passport (whereas normal behavior is only store most granular), a more isolated ruleset means we can only automate constraints-based questions/checklists now when it's an exact match (eg do not apply startsWith logic as a fallback if no direct matches like non-constraints passport values)
  • This is basically a more focused way to revisit this old pizza experiment wip: require exact match of data field segments for automations #3461 and fixes known issues like listed.grade.I, listed.grade.II both automating when it's only listed.grade.II

Known edges cases / not handled:

• If we don't check conservation areas, and you manually answer "yes" that you are in one, we aren't going to additionally manually assign/capture the parent-level designated passport value as the API response formatting would handle
  • This might be best handled by slightly adjusting which line items are actually selectable in the editor modal to begin with - eg should "Land designations" be the thing you can toggle, and that automatically queries or doesn't query everything that is prefixed designated. ? This is essentially how others like listed, flood are already doing?
• As you mentioned before, "checklist with some values that can be automated and others that haven't been seen" still persists for planning constraints and beyond. But I think that will fit in really nicely with Jonny's topic for next logic camp (eg maybe instead of full auto-answered, put to user auto-populated with option(s) we do know for certain) 🔖

All of my non-constraint automation test suites are still passing without changes so not expecting any wider changes or regressions beyond planning constraint-related questions.