Define delivery addresses, email templates, and notification preferences #9

New issue

Open

opened 2026-10-20 21:29:39 +00:00 by phg · 0 comments

phg commented

2026-10-20 21:29:39 +00:00

Owner

Part of #1

Question

What delivery and notification behavior should a member and administrator be able to configure?

Preserve email as voucher delivery in self-purchase mode, a selectable delivery address defaulting to account email, templated outgoing email, and optional PWA push. In central-purchase mode members never receive voucher codes; distinguish organizer-only voucher/return-address instructions from member-facing purchase and ticket messages. Decide the scope of a delivery address (account, event, or request), any confirmation requirement, and whether changes affect already assigned vouchers. Decide which event states produce email or push and how permission denied, unsupported browsers, expired subscriptions, and unsubscribing appear.

Settle who edits templates, template scope and variables, required voucher/return-address instructions, localization, preview and test behavior, and what sensitive information can appear on a lock screen. Use the Apple research for achievable states. Resolve policies for the prototype and specification; delivery retry mechanics belong to the recovery ticket.

Apply the composite lifecycle and Define upfront-payment tracking and refunds for central purchases: decide messages for payment instructions and receipt confirmation, insufficient/unmatched funding, organizer purchase progress, ticket availability/delivery, and refunds due or completed. Determine the intended recipients, privacy boundaries, and notification preferences. Preserve the agreed self-purchase fulfillment evidence: acceptance by the recipient's mail server, not merely local queuing or outgoing-provider acceptance. The chosen mail architecture must expose that evidence or bring an explicit mismatch back for decision.

Settled funding and refund input

Use the agreed resolution in Define upfront-payment tracking and refunds for central purchases. Use its participant/finance visibility boundaries and notification-event handoff when selecting recipients, channels, templates, and preferences for payment, correction, shortfall, purchase/recovery, and refund changes. Preserve its privacy limits for bank details, member numbers, and bank evidence in push previews.

Part of #1 ## Question What delivery and notification behavior should a member and administrator be able to configure? Preserve email as voucher delivery in self-purchase mode, a selectable delivery address defaulting to account email, templated outgoing email, and optional PWA push. In central-purchase mode members never receive voucher codes; distinguish organizer-only voucher/return-address instructions from member-facing purchase and ticket messages. Decide the scope of a delivery address (account, event, or request), any confirmation requirement, and whether changes affect already assigned vouchers. Decide which event states produce email or push and how permission denied, unsupported browsers, expired subscriptions, and unsubscribing appear. Settle who edits templates, template scope and variables, required voucher/return-address instructions, localization, preview and test behavior, and what sensitive information can appear on a lock screen. Use the Apple research for achievable states. Resolve policies for the prototype and specification; delivery retry mechanics belong to the recovery ticket. Apply the composite lifecycle and [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16): decide messages for payment instructions and receipt confirmation, insufficient/unmatched funding, organizer purchase progress, ticket availability/delivery, and refunds due or completed. Determine the intended recipients, privacy boundaries, and notification preferences. Preserve the agreed self-purchase fulfillment evidence: acceptance by the recipient's mail server, not merely local queuing or outgoing-provider acceptance. The chosen mail architecture must expose that evidence or bring an explicit mismatch back for decision. ## Settled funding and refund input Use the agreed resolution in [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16). Use its participant/finance visibility boundaries and notification-event handoff when selecting recipients, channels, templates, and preferences for payment, correction, shortfall, purchase/recovery, and refund changes. Preserve its privacy limits for bank details, member numbers, and bank evidence in push previews.

phg added the

wayfinder:grilling

needs-info

labels

2026-10-20 21:29:39 +00:00

phg added a new dependency

2026-10-20 21:29:44 +00:00

#3 Establish current Apple PWA push capabilities and constraints

phg added a new dependency

2026-10-20 21:29:44 +00:00

#11 Choose the application architecture and deployment contract

phg added a new dependency