Skip to content

CMS-1977: Calculate winter fee from edit published tab - #720

Open
ayumi-oxd wants to merge 2 commits into
mainfrom
CMS-1977
Open

CMS-1977: Calculate winter fee from edit published tab#720
ayumi-oxd wants to merge 2 commits into
mainfrom
CMS-1977

Conversation

@ayumi-oxd

@ayumi-oxd ayumi-oxd commented Aug 19, 2026

Copy link
Copy Markdown
Collaborator

Jira Ticket

CMS-1977

Description

  • Updated propagateWinterFeeDates.js so when a regular-season operation date is edited, winter-fee propagation also recalculates the same-year winter season (with a fallback if the prior winter season is missing).
  • Example:
For a regular season edit in year 2026, the function does two winter recalculations:

1. First pass targets winter 2025.
For winter 2025, overlap is calculated from:
- previousOperationRanges: regular 2025 operation dates
- currentOperationRanges: regular 2026 operation dates

2. Second pass targets winter 2026.
For winter 2026, overlap is calculated from:
- previousOperationRanges: regular 2026 operation dates
- currentOperationRanges: regular 2027 operation dates

So “this regular year is the previous operation year” means:
- in the same-year pass (winter 2026), the edited regular year (2026) is treated as previousOperationRanges, not currentOperationRanges.

Concrete date-combination example:

- Park winter 2026: 2026-10-15 to 2027-03-31
- Regular 2026 operation: 2026-04-01 to 2026-11-15
- Regular 2027 operation: 2027-02-01 to 2027-10-31

Winter 2026 overlap result becomes:
- 2026-10-15 to 2026-11-15 (from regular 2026)
- 2027-02-01 to 2027-03-31 (from regular 2027)
  • In seasons.js, the note validation was moved to run after that final status is decided, so validation uses the correct updated status.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates winter-fee propagation and season-save workflow so that editing regular-season operation dates can also trigger recalculation for the same-year winter season, and ensures certain edits to published seasons flow through an approved-save path where propagation occurs.

Changes:

  • Extend propagateWinterFeeDates with an overrideable target winter operating year and add logic to also propagate same-year winter for regular-season edits (with a fallback when the prior winter season is missing).
  • Adjust season save handling to downgrade published seasons to APPROVED when operation/winter-fee dates change, enabling winter-fee propagation on edits made from the published state.

Reviewed changes

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

File Description
backend/utils/propagateWinterFeeDates.js Adds optional targeting and additional propagation pass to cover same-year winter recalculation for regular-season edits.
backend/routes/api/seasons.js Modifies status-resolution flow for published edits so date changes can trigger propagation via an approved-save path.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread backend/routes/api/seasons.js Outdated
Comment thread backend/utils/propagateWinterFeeDates.js
@ayumi-oxd
ayumi-oxd marked this pull request as ready for review August 19, 2026 18:24
@ayumi-oxd
ayumi-oxd requested review from duncan-oxd and molund August 19, 2026 18:31

@duncan-oxd duncan-oxd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good, but I just want to clarify the naming to make sure I get it:

A winter season that starts in 2026 and ends in 2027 is operatingYear 2026
So the "current" regular season for that winter season is also operatingYear 2026
2027 would be the "next" and 2025 would be the "previous", all relative to that winter season.

A winter season spans 2 years, so it overlaps with 2 regular seasons

A regular season overlaps with 2 winter seasons? For example, a 2026 regular season. The 2025 winter season ends in early 2026 and the 2026 winter season starts in late 2026 (and continues into 2027). So 3 years are involved with each regular season, but it's only 2 operating years.

Is that all still true? :D Ready to merge, if so!

@ayumi-oxd

Copy link
Copy Markdown
Collaborator Author

@duncan-oxd

A regular season overlaps with 2 winter seasons? For example, a 2026 regular season. The 2025 winter season ends in early 2026 and the 2026 winter season starts in late 2026 (and continues into 2027). So 3 years are involved with each regular season, but it's only 2 operating years.

  • Yes, if Park A has a winter fee date (Oct 1, 2026 - Mar 31, 2027), that season's operating year is 2026.
  • For winter operating year 2026, propagation combines regular 2026 and regular 2027 (same year + next year), not regular 2025.
  • For regular operatingYear 2026, it overlaps two winter seasons: winter 2025 (ending in early 2026) and winter 2026 (starting in late 2026)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants