@blamejs/blamejs-shop 0.4.52 → 0.4.53

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.53 (2026-06-14) — **A signed-in customer's cookie choices and newsletter unsubscribe now land in the durable consent record.** The durable, per-customer consent ledger — the GDPR Article 7(1) record a controller keeps to demonstrate consent — is now written from the real consent events for identified customers. When a signed-in customer saves their cookie preferences, each category (functional, analytics, marketing, preferences) is recorded as granted or withdrawn in the durable ledger, alongside the existing session-level cookie record. When a newsletter unsubscribe resolves to a customer account, a marketing-email withdrawal is recorded there too. Anonymous visitors and email-only subscribers with no account are unchanged — their cookie choice stays in the session-level store and their unsubscribe in the email-suppression list, neither of which can be customer-keyed. The ledger writes are best-effort and never block the banner save or the unsubscribe. No migration to apply. **Added:** *Cookie-banner choices recorded in the durable consent ledger for signed-in customers* — When an authenticated customer saves their cookie preferences, each of the four optional categories is now mirrored into the durable per-customer consent ledger as a granted or withdrawn decision (source: cookie banner), so a supervisory-authority audit shows the identified individual's choice and not only the session-keyed record. The durable record reflects the consent the storefront actually enforces: a browser-level opt-out signal (Global Privacy Control or Do Not Track) collapses the analytics and marketing categories to withdrawn even if their boxes were ticked, matching the runtime gate, so the record never claims consent the app refuses to honor. The customer is resolved from the existing signed-in session (a revoked session is treated as signed-out); anonymous visitors carry no account and are written only to the session-level cookie record as before. · *Newsletter unsubscribe records a marketing withdrawal for account holders* — A newsletter unsubscribe that resolves to a customer account now records a marketing-email withdrawal in the durable consent ledger. The unsubscribed address is matched to an account by its hashed form; an email-only subscriber with no account is handled by the existing email-suppression path only, since the durable ledger is keyed by customer. The existing unsubscribe behavior — the suppression entry and the one-click RFC 8058 flow — is unchanged.
+
 - v0.4.52 (2026-06-14) — **Consent records now carry the GDPR Article 6 lawful basis they rest on.** Each decision in the durable per-customer consent ledger now records the GDPR Article 6(1) lawful basis it is processed under — consent, contract, legal obligation, vital interests, public task, or legitimate interests — alongside what was decided and when. The basis defaults from the consent kind (cookie categories, marketing email/SMS, and data-sharing opt-ins are all consent-based), and a caller may pass an explicit, validated basis for a record that rests on another. The basis is surfaced in the subject-access and supervisory-authority exports, so a consent audit now shows not just the decision but the legal ground for it. A migration adds a nullable, constrained lawful_basis column; pre-existing rows keep a null basis rather than being assigned one retroactively. Apply the pending migration on upgrade. **Added:** *Lawful basis on consent-ledger records* — The consent ledger now stamps the GDPR Article 6(1) lawful basis on every recorded decision. The basis defaults from the consent kind — every category the ledger tracks (cookie functional/analytics/marketing/preferences, marketing email, marketing SMS, partner and analytics data-sharing, and general data processing) is consent-based — and an explicit basis can be supplied and is validated against the six Article 6(1) values. Withdrawal records carry the same basis as the grant they revoke. The basis is included in the subject-access export (CSV and JSON) and the jurisdiction bulk export, so a consent audit shows the legal ground each decision rests on. **Changed:** *Migration: lawful_basis column on consent_ledger* — A new migration adds a nullable lawful_basis column to consent_ledger, constrained to the six Article 6(1) bases. The column is nullable and the constraint applies only to rows written after the migration, so existing records keep a null basis (not retroactively assigned) while every new record carries one. Apply the pending migration on upgrade.
 
 - v0.4.51 (2026-06-14) — **The order page now shows a dated activity timeline of the order's lifecycle.** A customer viewing their order now sees a chronological activity feed of what has happened to it — placed, payment received, shipped, delivered, cancelled, and refunds — newest first, each with its date and the relevant detail. A shipped event shows the carrier and tracking number when one was recorded; a refund shows its amount (and marks a partial refund as such); a click-and-collect delivery shows the pickup location. The feed is built from the order's own transition history and is scoped to the order being viewed, so it appears only to the order's owner or a guest holding the order's access link. Internal fulfillment bookkeeping and operator-process detail are not surfaced — only customer-meaningful milestones. The order page renders this server-side with no client JavaScript. No migration to apply. **Added:** *Order activity timeline on the order page* — The order detail page renders a dated, newest-first timeline of the order's lifecycle events: placed, payment received, shipped (with carrier and tracking number when present), delivered (with pickup location for click-and-collect), cancelled, and refunds (with the refunded amount, labelled partial when applicable). Events are drawn from the order's transition history and filtered to customer-meaningful milestones — internal fulfillment steps, raw state transitions, operator-process reasons, and payment-provider identifiers are never shown. Every rendered value is HTML-escaped, and the feed is shown only within the order's existing access scope (the signed-in owner or a guest order's access link).

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.52",
+  "version": "0.4.53",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/newsletter.js

@@ -303,6 +303,15 @@ function create(opts) {
         error:      "ok",
         signup_id:  row.signup_id,
         email_hash: signup ? signup.email_hash : null,
+        // The newsletter `email_hash` is keyed on the "newsletter-email"
+        // namespace and therefore never matches a customers-store lookup
+        // (which keys on "customer-email"). The plaintext address is what
+        // lets a caller re-derive the customer-namespace hash and decide
+        // whether this unsubscribe belongs to a real account (e.g. to
+        // record a durable per-customer marketing_email withdrawal). The
+        // signup row already persists `email_normalized` to act on the
+        // address; surface it here verbatim.
+        email_normalized: signup ? signup.email_normalized : null,
       };
     },
 

package/lib/storefront.js

@@ -21134,6 +21134,42 @@ function mount(router, deps) {
         // "already" — still a success page, no error).
         var result = await deps.newsletter.consumeUnsubscribeToken(token);
         outcome = _unsubscribeOutcome(result);
+
+        // Durable per-CUSTOMER consent of record (GDPR Art. 7(1)). The
+        // newsletter table is email-keyed — it has no customer_id — and its
+        // own opt-out (the unsubscribed_at stamp + the email-suppression
+        // entry) is unchanged above. But when the unsubscribed address ALSO
+        // belongs to a real customer account, the withdrawal is a decision
+        // by an identified data subject, so it lands in the durable,
+        // customer-keyed consent_ledger as a marketing_email withdrawal.
+        //
+        // The consume result's `email_hash` is keyed on the newsletter
+        // namespace and therefore never matches the customers store (which
+        // keys on a DIFFERENT namespace) — so resolution goes through the
+        // plaintext `email_normalized`, re-hashed under the customers
+        // namespace via customers.hashEmail. An email-only newsletter
+        // subscriber with no account resolves to null and is intentionally
+        // NOT written to the ledger (it can't be customer-keyed) — only the
+        // existing email-suppression applies. Drop-silent + best-effort: the
+        // unsubscribe already committed; an audit-trail write must never turn
+        // it into an error.
+        if (result && result.ok && result.email_normalized &&
+            deps.consentLedger && deps.customers &&
+            typeof deps.customers.byEmailHash === "function" &&
+            typeof deps.customers.hashEmail === "function") {
+          try {
+            var unsubCustHash = deps.customers.hashEmail(result.email_normalized);
+            var unsubCustomer = await deps.customers.byEmailHash(unsubCustHash);
+            if (unsubCustomer && unsubCustomer.id) {
+              await deps.consentLedger.recordConsentChange({
+                customer_id:  unsubCustomer.id,
+                consent_kind: "marketing_email",
+                state:        "withdrawn",
+                source:       "preference_center",
+              });
+            }
+          } catch (_eLedger) { /* drop-silent — the unsubscribe is authoritative; the durable ledger is the audit trail and must not block it */ }
+        }
       } catch (e) {
         // A real infrastructure fault (D1 unreachable) — record it server-
         // side and render the generic non-leaking page rather than a 500
@@ -21425,6 +21461,60 @@ function mount(router, deps) {
       } catch (_e) { /* drop-silent — the gate cookie is authoritative; the ledger write is the audit trail and must not block the decision */ }
     }
 
+    // Durable per-CUSTOMER consent of record (GDPR Art. 7(1)). The
+    // cookieConsent ledger above is session-keyed (hashed sid); it proves
+    // what a browser chose, not what an identified data subject chose. When
+    // the visitor is an authenticated customer, ALSO mirror each cookie
+    // category into the durable, customer-keyed consent_ledger so a
+    // supervisory-authority audit can demonstrate the named individual's
+    // decision. Anonymous / session-only visitors carry no customer_id and
+    // MUST NOT touch this ledger (recordConsentChange refuses a non-UUID),
+    // so the resolution below skips them and only the session-level record
+    // above is written. The resolver mirrors the stock-alert subscribe
+    // path: _currentCustomerEnv reads the sealed auth envelope; a present-
+    // but-revoked session is treated as signed-out so a withdrawn session
+    // can't keep stamping the ledger.
+    if (deps.consentLedger) {
+      var clCustomerId = null;
+      try {
+        var clEnv = _currentCustomerEnv(req);
+        if (clEnv && !(await _sessionRevoked(clEnv))) clCustomerId = clEnv.customer_id;
+      } catch (_eAuth) { clCustomerId = null; }
+      if (clCustomerId) {
+        // Map the four toggleable cookie categories to their consent_ledger
+        // kinds; on = granted, off = withdrawn. Each write is independent
+        // and drop-silent so a single failure can't strand the others or
+        // block the banner save.
+        // A browser-level opt-out (GPC / DNT) forces analytics + marketing
+        // off no matter what the posted checkbox says — exactly the collapse
+        // the runtime gate _consentAllows applies. The durable ledger has no
+        // signal column, so it must record the EFFECTIVE consent the app
+        // enforces, not the raw click: otherwise the customer record would
+        // claim consent for a category the app treats as withdrawn.
+        var clOptOut = _browserOptOut(req);
+        var clMap = [
+          ["functional",  "cookies_functional"],
+          ["analytics",   "cookies_analytics"],
+          ["marketing",   "cookies_marketing"],
+          ["preferences", "cookies_preferences"],
+        ];
+        for (var clI = 0; clI < clMap.length; clI += 1) {
+          var clCat   = clMap[clI][0];
+          var clKind  = clMap[clI][1];
+          var clOn    = cats[clCat] === true;
+          if ((clCat === "analytics" || clCat === "marketing") && clOptOut) clOn = false;
+          try {
+            await deps.consentLedger.recordConsentChange({
+              customer_id:  clCustomerId,
+              consent_kind: clKind,
+              state:        clOn ? "granted" : "withdrawn",
+              source:       "cookie_banner",
+            });
+          } catch (_eLedger) { /* drop-silent — the gate cookie is authoritative; the durable ledger is the audit trail and must not block the decision */ }
+        }
+      }
+    }
+
     var dest = _consentReturnTo(body.return_to, "/");
     res.status(303);
     res.setHeader && res.setHeader("location", fromManage ? "/cookies?saved=1" : dest);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.52",
+  "version": "0.4.53",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {