A subscription froze its planVersionId at sale (reproducible pricing). There was
no way to move a sold sub onto a different VERSION of the SAME plan — needed when
an admin publishes v2 with different timeframes (e.g. mujor-naten-cdo-dite v1
"every day" → v2 "weekdays only") and wants an existing subscriber on it, or back
on v1.
Backend (PUT /api/subscriptions/:id):
- accept planVersionId; honored only with the subscription:plan permission
(stronger than subscription:update — a plan-management action). Non-privileged
caller sending a change → 403, not silently dropped.
- validated to belong to the sub's EXISTING planId (a different plan = a
different price basis = a re-sale → 400).
- price/currency/period/planId stay frozen; only planVersionId moves. The swap is
server-logged for audit (the row is mutable master data, not on the ledger).
Past signed entry/exit events keep their own windowTariffVersionId, so history
reprices identically — only future access uses the new version's windows.
Frontend (SubscriptionManager):
- pass the session user through the route (like RolesManager).
- admin-only "Versioni" picker in the edit modal: lists every version of the
sub's plan by effective date + a timeframe summary (days + window, or 24/7),
current pre-selected. The plan itself stays read-only. Sends planVersionId only
when it changed.
- i18n: subs.version/versionHint/versionCurrent/versionOnlyOne/everyDay/allDay
in both sq + en.
Verified on a writable DB copy: version changed, price + planId frozen,
cross-plan version rejected. Live DB untouched. build+lint 14/14.
Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
julian
78d1f6808a