Changelog

All notable changes to Generous.nz are recorded here, grouped by version. Every deployed build has a version number, a git tag, and an entry below.

Versioning scheme

Versions follow MAJOR.MINOR.PATCH:

0.x — pre-launch. Minor bumps mark a completed build phase or major feature set; patches are bug fixes on the current build.
1.0.0 — first public launch.
1.x+ — post-launch: minor = new features, patch = fixes, major = breaking changes or significant re-architecture.

Each version is tagged in git (v0.2.0) and the current version is kept in package.json. See docs/version-control.md for how to cut a release.

Voucher codes moved to the product page + sold codes never reused.

Voucher code management moved out of the catalogue cards and into the product's edit page (where there's room): generate or paste codes there. Creating a new voucher takes you straight to its edit page so you can add codes immediately.
Sold vouchers stay sold: a code that has been purchased is never returned to the pool, even if the order is later refunded — it stays marked as assigned to that order, so it can't be resold.
Voucher sales page now shows the voucher code, the purchaser, and a "🎁 Gifted to [name] ([email])" line when the buyer selected the gift option at checkout.

Vouchers can be bought as gifts.

Voucher purchases now have a "This is a gift" option on the buy button. When selected, the purchaser enters the recipient's name, email and an optional message, and the voucher is emailed to the recipient (with the message) and a copy goes to the purchaser.

Brands page explainer + one-click first brand.

The Brands page now explains what brands are (sell multiple product lines under one store and one payout account) with real use cases, and how to set one up (create → tag products → it appears on the catalogue).
One-click first brand: if the store has no brands, a highlighted card creates a brand named after the business with a single click.

Removed references to other sites.

Removed all mentions of other platforms (e.g. "XXXXX-style") from user-facing copy and code comments. Feature descriptions now stand on their own.

Zero-downtime deploys.

The server deploy process now builds the site into a separate directory and atomically swaps it in, so the live site keeps serving the current build throughout the update — no more "Internal Server Error" / "client-side exception" windows during releases.
Dependencies are only reinstalled when the lockfile actually changes, so node_modules is no longer wiped on every push.

The intermittent TypeError: a is not a function / module-not-found errors during deploys were the old process serving while npm ci and next build replaced files under it. Deploys no longer disturb the running site.

Restriction conflicts hide wholesale items.

When every one of a signed-in fundraiser's approved campaigns conflicts with a wholesaler's restriction (e.g. the fundraiser ticked "Political party campaigns" and the business excludes it), the wholesaler's items are now hidden entirely from the catalogue and deal pages for that user — not just blocked at add time.
If only some of the user's campaigns conflict, items stay visible and can still be added to the campaigns that don't conflict. Signed-out visitors and users with no approved campaigns see everything.
The server-side add block remains as a final guard.

"Political party campaigns" cause option.

Political party campaigns is now a first-class cause option in the fundraiser setup checkboxes, the wholesaler Restrictions list, and the AI reason verification — so fundraisers can declare it and businesses can block it automatically.

Deploy-safe service worker — no more client-side crashes after updates.

The client-side exception after deploys was the service worker serving the old app shell (cached under a fixed name) after a release, referencing JS files the new build had deleted. The service worker now:
- versions its cache automatically with each release (the cache name is the site version), so every deploy clears all stale cached copies in visitors' browsers the moment the new worker activates;
- caches pages under their own URL (not all under "/") and only ever serves them as an offline fallback after a network failure;
- never caches error responses.
The service worker is generated at build time from a template, so the cache version can't drift.

If you hit the error once, a hard refresh (Ctrl+Shift+R) clears it; from now on it won't recur after future updates.