0.493.0

Release : pillar2-frontend 0.493.0

Last commit sha : 3c77112
Last commit author : olakunlekuye2
Last commit time : 2026-03-13T15:56:45Z

PIL-2855: Display Multiple Accounting Periods on Manage Group Details (#648)

Migrates the frontend to use the new Read Subscription V2 endpoint
(which returns an array of accounting periods) behind the
amendMultipleAccountingPeriods feature flag, while retaining full
backward compatibility with the existing V1 flow.

ETMP are introducing a breaking change to the Display Subscription API.
Replacing a singular accounting period with an array of accounting
periods. This PR introduces a V2 path on the frontend that consumes the
new response shape, converts it to the existing SubscriptionLocalData
cache model, and allows both V1 and V2 data to coexist without
invalidating any user's cache.

This also adds the first page of the new amend multiple accounting
periods journey -the Manage Group Details summary page now renders a
multi-period view with individual period cards when the feature flag is
enabled.

Additionally, this work exposed a pre-existing bug in the BTN flow where
the confirmation page and submission payload were using the accounting
period from the subscription data rather than the period the user
actually selected during the journey. This has been fixed so the entire
BTN flow now consistently uses the user's chosen period.

What changed

Models

• SubscriptionDataV2 — New model representing the V2 API response
  with Seq[DisplayAccountingPeriod] (each period includes
  canAmendStartDate/canAmendEndDate flags).
• DisplayAccountingPeriod — New model for individual accounting
  periods in the V2 response, with a toAccountingPeriod conversion
  helper.
• SubscriptionLocalData — Two new optional fields added with
  defaults for backward compatibility:
• accountingPeriods: Option[Seq[DisplayAccountingPeriod]] — populated
  from V2 data.
• registrationDate: Option[LocalDate] — populated from V2
  upeDetails. This was added so the homepage can display the
  registration date through the V2 path without requiring a separate
  homepage-specific model or a second API call (in the V1 flow, this value
  comes directly from SubscriptionData.upeDetails.registrationDate).
• subAccountingPeriod changed from AccountingPeriod to
  Option[AccountingPeriod] = None — V2 data no longer synthesises a fake
  singular period; V1 cached data continues to populate it as Some.

Connector

• readSubscriptionV2 — New method on SubscriptionConnector
  calling the backend V2 endpoint. Handles 404 as NoResultFound
  (consistent with V1 pattern), 422 as UnprocessableEntityError, and
  5xx with the existing retryable gateway error logic.

Service

• readSubscriptionV2AndSave — New method on SubscriptionService
  that calls readSubscriptionV2, converts the response to
  SubscriptionLocalData (populating accountingPeriods,
  registrationDate, and leaving subAccountingPeriod = None), and saves
  to the user-cache.
• subscriptionDataV2ToLocalData — Private conversion from
  SubscriptionDataV2 to SubscriptionLocalData.
• amendGroupOrContactDetails — Updated to handle optional
  subAccountingPeriod, falling back to currentData.accountingPeriod
  from the V1 SubscriptionData when None.

Homepage

• HomepageController.onPageLoad — When
  amendMultipleAccountingPeriods is enabled, calls
  readSubscriptionV2AndSave and renders the homepage from
  SubscriptionLocalData fields. When disabled, retains the original V1
  maybeReadSubscription + cacheSubscription flow.

Manage Group Details

• ManageGroupDetailsCheckYourAnswersController — When the flag is
  enabled, fetches V2 data and renders a multi-period summary view with
  individual period cards showing amendable date ranges.
• ManageGroupDetailsMultiPeriodView — New view template for
  rendering multiple accounting periods with Change links.

BTN Flow

Decoupled the BTN flow from subAccountingPeriod entirely — all BTN
controllers now source the accounting period from the user's chosen
period (BTNChooseAccountingPeriodPage in user answers):

• BTNConfirmationController — Confirmation page dates come from
  the chosen period, not subscription data.
• CheckYourAnswersController — Both onPageLoad (summary display)
  and onSubmit (BTN payload) use the chosen period. Falls back to
  subAccountingPeriod only on the CYA summary as a last resort, with
  JourneyRecovery redirect if neither is available.
• BTNAccountingPeriodController — Audit event uses the period from
  selectAccountingPeriod context directly.
• BTNStatusAction — Reads BTNChooseAccountingPeriodPage from
  user answers for the already-submitted audit.

Feature flag

All V2 behaviour is gated behind
features.amendMultipleAccountingPeriods (defaults to false). When
false, the frontend behaves identically to before this PR.

---

Co-authored-by: JamesMMiller 7511223+JamesMMiller@users.noreply.github.com