bermudalambandClaude Opus 5
f626f27e75
Customers can favorite and unfavorite items from the storefront, opt in to being told when a favorite is sold to someone else, and manage that preference from their account page. The opt-in is a consent of its own rather than the existing marketing flag. Being told that a specific item you asked about has gone is a narrower thing than agreeing to marketing, and folding one into the other would leave marketing_consent_text no longer describing what was actually agreed to. It is recorded the same way as the marketing consent — flag, timestamp, and the exact wording shown — and accepting it does not set marketing_consent. The prompt appears only after a customer has actually favorited something, so the reason for asking is concrete rather than an abstract marketing ask, and it says plainly that it is separate from marketing email. Declining keeps the favorite. Notifications fire when an item reaches sold, either through checkout or an admin marking it sold, and never to the buyer — telling someone the item they just bought is unavailable reads as a bug. Reserved is deliberately not a trigger: reservations expire and get released, so a "gone" email would often be about an item still for sale. Disabled accounts are excluded, per #33. completeCheckout now returns the sold item ids and the buyer so its three call sites can notify after COMMIT. Sending inside the transaction would email people about a sale that then rolled back, and would hold the transaction open for SMTP. Each message is sent independently so one bad address cannot stop the rest, and the sale has already succeeded regardless. Favoriting while signed out opens the existing inline register/login modal, exactly as Add to Cart does, and completes the favorite on success. Also fixes a latent bug in the same component: while the session was still resolving, `customer` is null for a signed-in visitor too, so clicking Add to Cart or the new heart in that window prompted them to sign in again. Both now ignore clicks until the session has resolved, and the control shows as loading meanwhile. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
35 lines
1.5 KiB
JavaScript
35 lines
1.5 KiB
JavaScript
exports.up = (pgm) => {
|
|
pgm.sql(`
|
|
CREATE TABLE IF NOT EXISTS favorites (
|
|
customer_id INTEGER NOT NULL REFERENCES customers(id) ON DELETE CASCADE,
|
|
item_id INTEGER NOT NULL REFERENCES items(id) ON DELETE CASCADE,
|
|
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
|
PRIMARY KEY (customer_id, item_id)
|
|
);
|
|
|
|
-- The primary key covers lookups by customer. Notifying everyone who
|
|
-- favorited an item that just sold goes the other way.
|
|
CREATE INDEX IF NOT EXISTS favorites_item_id_idx ON favorites (item_id);
|
|
|
|
-- A consent of its own rather than reusing marketing_consent. Being told
|
|
-- that a specific item you asked about has gone is a narrower thing than
|
|
-- agreeing to marketing, and folding one into the other would make the
|
|
-- existing consent record no longer describe what was agreed to.
|
|
--
|
|
-- Mirrors the marketing consent columns: the flag, when it was given, and
|
|
-- the exact wording shown at the time.
|
|
ALTER TABLE customers ADD COLUMN IF NOT EXISTS favorite_alerts BOOLEAN NOT NULL DEFAULT false;
|
|
ALTER TABLE customers ADD COLUMN IF NOT EXISTS favorite_alerts_at TIMESTAMPTZ;
|
|
ALTER TABLE customers ADD COLUMN IF NOT EXISTS favorite_alerts_text TEXT;
|
|
`);
|
|
};
|
|
|
|
exports.down = (pgm) => {
|
|
pgm.sql(`
|
|
ALTER TABLE customers DROP COLUMN IF EXISTS favorite_alerts_text;
|
|
ALTER TABLE customers DROP COLUMN IF EXISTS favorite_alerts_at;
|
|
ALTER TABLE customers DROP COLUMN IF EXISTS favorite_alerts;
|
|
DROP TABLE IF EXISTS favorites;
|
|
`);
|
|
};
|