migrate: find+replace article4, listed building grades, and flood zone fn
#4151
Conversation
|
Removed vultr server and associated DNS entries |
…ss/migrate-constraint-fns
| @@ -41,6 +41,14 @@ export function handleOverrides( | |||
| ); | |||
| } | |||
|
|
|||
| const gradeAndZoneLookup: Record<string, string> = { | |||
There was a problem hiding this comment.
Noob question here - is there a reason "1": "One" isn't included in this mapping?
There was a problem hiding this comment.
Good question! Planning Data only hosts data for Flood Zones 2 & 3, not 1 ! PlanX content may have separate questions about Flood Zone 1 that are manually put to user which we've accounted for in content migration, but when dealing only with GIS API response we don't need to worry about 1 since it's never automatically checked/fetched 👍
There was a problem hiding this comment.
@jessicamcinchak Sorry just seen you've merged this.
There's an outstanding article4 here on this branch which I think also needs to update (?) - https://github.com/theopensystemslab/planx-new/blob/jess/migrate-constraint-fns/editor.planx.uk/src/@planx/components/PlanningConstraints/List.tsx#L175
Apologies for the basic question about the mapping - feel like there's something basic I've missed here...!
| const zoneLookup: Record<string, string> = { | ||
| "flood.zone.2": "flood.zoneTwo", | ||
| "flood.zone.3": "flood.zoneThree", | ||
| }; |
There was a problem hiding this comment.
I think I'm missing something here sorry - might just be a part of the sequencing.
What we're doing below is mapping the old values (incoming request) to the new values (response sent to Editor).
The data migration is updating all values, why do we need this mapping?
There was a problem hiding this comment.
Sorry another opaque change/lack of code comment on my part ! These lookups are still necessary outside of actual content migration to correctly map the incoming Planning Data entity's flood-risk-level property to our correct data field.
Previously, our 2, 3, I, II, II* data value segments lined up exactly the same as Planning Data's values - but now they don't! See diff below as example -
Before: (entity) => entity["flood-risk-level"] === zone.split(".").pop()
After: (entity) => entity["flood-risk-level"] === oldZone.split(".").pop()
It's a bit messy but didn't think of a nicer way to handle this!
There was a problem hiding this comment.
Ah perfect - that's the bit I'm missing - Planning Data are of course still using 2, 3 etc 👍
I was caught out by the old in the name here I think in combination with the migrations. Maybe just a comment like this will do?
// This maps the PlanningData key to the PlanX key
const zoneLookup: Record<string, string> = {| source: "Planning Data", | ||
| datasets: ["article4-direction-area"], | ||
| datasets: ["article-4-direction-area"], |
There was a problem hiding this comment.
This change surprised me - was this just wrong since these options were introduced?
There was a problem hiding this comment.
Yes this was just wrong! Sorry didn't better highlight this.
These datasets are currently duplicated between API "base" metadata (actually referenced to make request) and editor modal (shown for source context only) - this is now corrected & future step here is to move to planx-core to remove duplication?
There was a problem hiding this comment.
Perfect - thanks for clarifying - this was what I figured 👍
Updates GIS API, Planning Constraints editor modal "select-able" datasets, and all mocks per data migration plan here https://docs.google.com/spreadsheets/d/1Vtxp5BLweDPDooQoNhgOCYjCIBPRYIcOuyArGJRqOkI/edit?gid=1809688754#gid=1809688754