CMS-1933: Use Strapi dateTypeNumber to identify dateTypes

[duncan-oxd]

Jira Ticket

CMS-1933

Don't merge for v2.5.0

The ticket specifies that they want to keep the CMS/DB the same, and only add this as a display later in the template. I think these are still good changes to make, so I'll keep this branch, but I'll add another one for v2.5.0 that only changes the frontend.

Description

The team needs to change the name of the "Operating" date type in the DB. This branch updates the whole app to use the "dateTypeNumber" field from Strapi to work with date types instead of the name field. Now we can change the name in the CMS and sync it back into DOOT and the app will still work.

I updated the validation rules and the frontend template code as well as the backend API payloads and the scripts in /tasks. This branch also fixes a couple of small bugs where stuff would silently fail if dateType records changed before.

You can test this one by changing a date type "name" value in Strapi and running the npm run cron-task to pull the change into DOOT. I changed "Operating" to a test string in this screenshot:

I'll mention in the ticket, one thing to NOTE: Some of the validation messages still specifically mention date types by name:

"The reservation dates must not overlap with winter dates. (To change winter dates, edit the park)",

If we change "reservation" or "winter" to something else, we'd also want to update those messages. We can eventually move the validation/error messages into the ui-text file along with the tooltip text so the strings can be reviewed and updated all in one place.

[duncan-oxd]

We'll probably never run this one-time script or use this data again, but I updated it anyway for completeness.

[Copilot]

Pull request overview

Updates the app’s date-type handling to rely on Strapi’s stable dateTypeNumber identifiers (instead of mutable name strings), so CMS renames (e.g., “Operating”) won’t break validation, filtering, exports, or backend tasks.

Changes:

• Replaced dateType.name comparisons with dateType.dateTypeNumber across frontend filters and validation rules.
• Updated backend utilities/routes/tasks to query and filter by dateTypeNumber and refreshed task docs/data accordingly.
• Adjusted validation error-slot targeting to derive the displayed date-type name from loaded data, keeping UI anchors aligned after renames.

Reviewed changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/src/lib/submitPageFilters.js	Uses dateTypeNumber constants for submit-page filtering logic.
frontend/src/hooks/useValidation/rules/winterDateYears.js	Switches winter-fee detection to dateTypeNumber.
frontend/src/hooks/useValidation/rules/winterAndReservationNoOverlap.js	Uses dateTypeNumber for winter-fee selection and derives slot name dynamically.
frontend/src/hooks/useValidation/rules/tier1And2SameAsReservation.js	Uses dateTypeNumber for Tier 1/2 selection and derives slot names dynamically.
frontend/src/hooks/useValidation/rules/tier1And2NoOverlap.js	Uses dateTypeNumber for Tier 1/2 selection and derives slot names dynamically.
frontend/src/hooks/useValidation/rules/reservationWithinOperating.js	Groups by dateTypeNumber and derives slot names dynamically for reservation/operation validations.
frontend/src/hooks/useValidation/rules/reservationSameAsTier1And2.js	Uses dateTypeNumber for reservation selection and derives slot name dynamically.
frontend/src/hooks/useValidation/rules/reservationEndsBeforeOperatingEnds.js	Groups by dateTypeNumber and derives slot names dynamically for reservation/operation validations.
frontend/src/hooks/useValidation/rules/reservationAndWinterNoOverlap.js	Uses dateTypeNumber for reservation selection and derives slot name dynamically.
frontend/src/hooks/useValidation/rules/requiredDateRanges.js	Uses dateTypeNumber when determining optional vs required date types.
frontend/src/hooks/useValidation/rules/dateInOperatingYear.js	Uses dateTypeNumber to exempt winter-fee dates from the operating-year rule.
frontend/src/components/SubmitPageTable.jsx	Formatting-only change to the Edit IconButton (no functional impact).
frontend/src/components/FormPanel.jsx	Uses DATE_TYPE.PARK_GATE_OPEN constant instead of hard-coded index.
frontend/src/components/DateRangeFields.jsx	Uses dateTypeNumber for Tier 1/2 UI logic; updates prop types accordingly.
backend/utils/firstComeFirstServedHelper.js	Uses dateTypeNumber for DateType lookups and DateRange filtering/creation.
backend/tasks/populate-previous-dates/README.md	Updates docs to reference dateTypeNumber for matching.
backend/tasks/populate-previous-dates/previous-dates.json	Adds dateTypeNumber to seed entries.
backend/tasks/populate-previous-dates/populate-previous-dates.js	Uses dateTypeNumber instead of name to find DateTypes.
backend/tasks/delete-reservation-date-ranges/README.md	Updates docs to reference dateTypeNumber for Reservation DateType lookup.
backend/tasks/delete-reservation-date-ranges/delete-reservation-date-ranges.js	Uses dateTypeNumber to locate Reservation DateType.
backend/tasks/create-seasons/create-seasons.js	Uses dateTypeNumber to locate Tier 2 DateType.
backend/tasks/create-date-range-annual/README.md	Updates docs to describe Tier 1/2 exclusion via dateTypeNumber.
backend/tasks/create-date-range-annual/create-date-range-annual.js	Uses dateTypeNumber to exclude Tier 1/2 from annual entries.
backend/routes/api/parks.js	Uses dateTypeNumber when filtering reservation date ranges.
backend/routes/api/export.js	Uses dateTypeNumber when skipping reservation and FCFS date ranges.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.