CMS-1613: Add Feature "datesCanSpan2Years" field#1845
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new boolean field to the Strapi park-feature content type to support upcoming validation rule bypasses for features whose operating dates can span across two calendar years, and includes a CMS DB migration to backfill/populate this field for a known set of features.
Changes:
- Add
datesCanSpan2yearsboolean attribute (defaultfalse, required) to thepark-featureStrapi schema. - Add a Knex migration that ensures the backing column exists and sets
dates_can_span_2_years = truefor specificfeature_idvalues.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/cms/src/api/park-feature/content-types/park-feature/schema.json | Adds the new Strapi boolean attribute to the park-feature content type. |
| src/cms/database/migrations/2026.05.29T00.00.011-populate-feature-dates-can-span-2years.js | Adds/updates the CMS DB column and populates true for a predefined set of features. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Update the specified features to have their datesCanSpan2years value set to true | ||
| await knex("park_features") | ||
| .whereIn("feature_id", featureIds) | ||
| .update({ dates_can_span_2_years: true }); |
There was a problem hiding this comment.
I don't think this is necessary if the column is being created right here in the migration, but I can update it if it's risky
f5cea61 to
256bed8
Compare
|
Note that I just pushed an update to rename the field to datesCanSpan2Years with a capital "Y" 👍 I mentioned it to UX that it's the convention when naming fields like this. |
Jira Ticket:
CMS-1613
Description:
Part 1 of the multi-part task to allow certain features to bypass some validation rules. This adds a boolean flag field "Dates can span 2 years" to Strapi. The next steps are:
I tagged this with 3.1.0 for now but we can change it. It just needs to go to production before the associated DOOT update does.
Instead of the "two start" migration pattern we were using in the past, this creates the new fields in the migration so it only needs to run once. 👍