Define administrator authority, queue visibility, and event lifecycle #10

New issue

Open

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

phg commented

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

Owner

Part of #1

Question

What may members and administrators see and change within a single-hackerspace installation?

Decide who can create/open/pause/close/archive an event; whether joining is separate from signup and event access; whether members see names, quantities, exact positions, or only their own progress; and how administrator adjustments preserve or explicitly override the selected allocation policy's promises. Cover initial voucher import, handling suspicious incoming mail, disabling an account, and invitation administration.

Determine which actions require an audit trail, what voucher secrets are visible, and the intended data retention/deletion boundary for completed events. Scope the admin journeys to expose these choices in all four designs. Resolve product policy with the human, not a legal-compliance claim or implementation checklist.

Use Define allocation policies and organizer-triggered shuffling for policy-selection/change rules, Define central-purchase workflow and fulfillment for purchase-mode scope and organizer duties, and Define upfront-payment tracking and refunds for central purchases for funding/refund states. Define Orga-team capabilities separately from ordinary members and decide their relationship to administrators: accessing central-purchase vouchers, claiming and recording purchases, confirming/correcting bank receipts, viewing balances or refund details, and approving/recording refunds. Decide who can trigger the initial shuffle and change event policies/modes, applying the allocation-policy cutoff at the first voucher sent or first ticket bought by the Orga-team. Settle what members see in the fixed post-shuffle order, and what event closure does to outstanding purchases and refundable funds. Do not expose central-purchase voucher codes through member views, exports, or notifications.

Settled funding and refund input

Use the agreed resolution in Define upfront-payment tracking and refunds for central purchases. Apply its separate finance permission, private financial views, audit history, and outstanding purchase/refund treatment. Include organizer configuration of dynamic ticket tiers and tier-required holder details, such as a member number. Decide role assignment and lifecycle actions here without reopening settled financial rules.

Part of #1 ## Question What may members and administrators see and change within a single-hackerspace installation? Decide who can create/open/pause/close/archive an event; whether joining is separate from signup and event access; whether members see names, quantities, exact positions, or only their own progress; and how administrator adjustments preserve or explicitly override the selected allocation policy's promises. Cover initial voucher import, handling suspicious incoming mail, disabling an account, and invitation administration. Determine which actions require an audit trail, what voucher secrets are visible, and the intended data retention/deletion boundary for completed events. Scope the admin journeys to expose these choices in all four designs. Resolve product policy with the human, not a legal-compliance claim or implementation checklist. Use [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14) for policy-selection/change rules, [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15) for purchase-mode scope and organizer duties, and [Define upfront-payment tracking and refunds for central purchases](https://git.s1q.dev/MISChaufen/prevouch/issues/16) for funding/refund states. Define Orga-team capabilities separately from ordinary members and decide their relationship to administrators: accessing central-purchase vouchers, claiming and recording purchases, confirming/correcting bank receipts, viewing balances or refund details, and approving/recording refunds. Decide who can trigger the initial shuffle and change event policies/modes, applying the allocation-policy cutoff at the first voucher sent or first ticket bought by the Orga-team. Settle what members see in the fixed post-shuffle order, and what event closure does to outstanding purchases and refundable funds. Do not expose central-purchase voucher codes through member views, exports, or notifications. ## 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). Apply its separate finance permission, private financial views, audit history, and outstanding purchase/refund treatment. Include organizer configuration of dynamic ticket tiers and tier-required holder details, such as a member number. Decide role assignment and lifecycle actions here without reopening settled financial rules.

phg added the

wayfinder:grilling

needs-info

labels

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

phg added a new dependency

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

#11 Choose the application architecture and deployment contract

phg added a new dependency

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

#12 Evaluate member and admin journeys in four live-switchable designs

phg referenced this issue