[Feature] Define generic public self-enrolment links #5

New Issue

2026-07-22T04:36:04+02:00

zemion commented

2026-07-22 04:36:04 +02:00

Goal

Define and implement a generic public Scheduling link through which a person who was not pre-created as a participant can enrol and submit a response.

This is distinct from the existing personalized, signed participant links. Those links remain bound to an existing participant and may be copied or sent explicitly by an organizer. Creating or updating a Scheduling request does not send invitations automatically.

Decisions required

Which identity details must an anonymous participant provide: display name, email address, both, or policy-selected fields?
When a signed-in account follows the link, should the response bind automatically to that account, ask for confirmation, or permit an unbound response?
How should a later sign-in reconcile an anonymous response with an account?
What constitutes the same participant for duplicate prevention, especially with aliases and shared email addresses?
May generic links create unlimited participants, or must the organizer set a capacity and/or enrolment deadline?
Which deployment, tenant, request, and policy controls can enable public enrolment?
What throttling, challenge, password, moderation, or approval controls are required against abuse?
Which participant identity and response details may other participants see?
Should mail delivery ever create personalized links from a generic invitation, or should generic and personalized delivery remain separate?
What must be retained in the audit trail when an anonymous identity is edited, merged, rejected, revoked, or bound to an account?

Required design properties

Preserve tenant isolation and do not disclose whether an account or address exists.
Keep bearer credentials out of URLs returned to unauthorized viewers, logs, analytics, and browser storage.
Apply deployment-wide throttling with Redis when available and a safe single-node fallback for development.
Keep enrollment and response submission idempotent under retries and concurrent requests.
Make all identity reconciliation and organizer moderation auditable.
Keep existing organizer-created participants and personalized links backward compatible.
Surface disabled/unavailable actions through the central UI components rather than hiding them.

Acceptance outline

Implementation can begin after the decisions above are recorded as policy defaults and configuration hooks. It should include API and WebUI threat tests, concurrency tests, link expiry/revocation tests, account-binding tests, privacy tests, documentation topics with required scopes, and explicit migration/backward-compatibility treatment.

## Goal Define and implement a generic public Scheduling link through which a person who was not pre-created as a participant can enrol and submit a response. This is distinct from the existing personalized, signed participant links. Those links remain bound to an existing participant and may be copied or sent explicitly by an organizer. Creating or updating a Scheduling request does not send invitations automatically. ## Decisions required - Which identity details must an anonymous participant provide: display name, email address, both, or policy-selected fields? - When a signed-in account follows the link, should the response bind automatically to that account, ask for confirmation, or permit an unbound response? - How should a later sign-in reconcile an anonymous response with an account? - What constitutes the same participant for duplicate prevention, especially with aliases and shared email addresses? - May generic links create unlimited participants, or must the organizer set a capacity and/or enrolment deadline? - Which deployment, tenant, request, and policy controls can enable public enrolment? - What throttling, challenge, password, moderation, or approval controls are required against abuse? - Which participant identity and response details may other participants see? - Should mail delivery ever create personalized links from a generic invitation, or should generic and personalized delivery remain separate? - What must be retained in the audit trail when an anonymous identity is edited, merged, rejected, revoked, or bound to an account? ## Required design properties - Preserve tenant isolation and do not disclose whether an account or address exists. - Keep bearer credentials out of URLs returned to unauthorized viewers, logs, analytics, and browser storage. - Apply deployment-wide throttling with Redis when available and a safe single-node fallback for development. - Keep enrollment and response submission idempotent under retries and concurrent requests. - Make all identity reconciliation and organizer moderation auditable. - Keep existing organizer-created participants and personalized links backward compatible. - Surface disabled/unavailable actions through the central UI components rather than hiding them. ## Acceptance outline Implementation can begin after the decisions above are recorded as policy defaults and configuration hooks. It should include API and WebUI threat tests, concurrency tests, link expiry/revocation tests, account-binding tests, privacy tests, documentation topics with required scopes, and explicit migration/backward-compatibility treatment.

zemion added the area/api codex/ready module/scheduling

labels 2026-07-29 14:15:01 +02:00

zemion commented

2026-07-30 21:48:38 +02:00

Codex State: ready

Summary

Product defaults confirmed: require a display name; make email collection policy-controlled.
Signed-in participants confirm account binding; anonymous responses retain proof for an explicit later link.
Use capacity/deadline controls, Redis-backed throttling/challenges, and minimal participant visibility.

Suggested status label: status/ready

## Codex State: ready ### Summary - Product defaults confirmed: require a display name; make email collection policy-controlled. - Signed-in participants confirm account binding; anonymous responses retain proof for an explicit later link. - Use capacity/deadline controls, Redis-backed throttling/challenges, and minimal participant visibility. Suggested status label: `status/ready`

zemion commented

2026-08-20 13:22:46 +02:00

Codex State: ready

Summary

Implemented reusable governed public self-enrolment links with expiry, capacity, identity-mode policy, proof-based recovery, account binding, revocation, throttling, idempotency, and UI.
Local commits: Scheduling 539e3cb, Core 026e451, workspace 83ccb7f.

Verification

Targeted self-enrolment and migration tests: 11 passed.
tools/checks/check-focused.sh: passed the integrated backend, manifest, UI-contract, 59-permutation build, and Playwright conformance gate.

Next / Blocked

Push the local commits, run remote CI, then close the issue after integration.

Suggested status label: status/ready

## Codex State: ready ### Summary - Implemented reusable governed public self-enrolment links with expiry, capacity, identity-mode policy, proof-based recovery, account binding, revocation, throttling, idempotency, and UI. - Local commits: Scheduling 539e3cb, Core 026e451, workspace 83ccb7f. ### Verification - `Targeted self-enrolment and migration tests: 11 passed.` - `tools/checks/check-focused.sh: passed the integrated backend, manifest, UI-contract, 59-permutation build, and Playwright conformance gate.` ### Next / Blocked - Push the local commits, run remote CI, then close the issue after integration. Suggested status label: `status/ready`

zemion commented

2026-08-20 19:11:47 +02:00

Published and verified on remote main: Scheduling 539e3cb, Core 026e451, workspace 83ccb7f. The repository has no configured commit-status contexts/workflow files; the recorded complete focused workspace gate is the integration evidence. Acceptance criteria are satisfied, so this issue is being closed.

Published and verified on remote `main`: Scheduling 539e3cb, Core 026e451, workspace 83ccb7f. The repository has no configured commit-status contexts/workflow files; the recorded complete focused workspace gate is the integration evidence. Acceptance criteria are satisfied, so this issue is being closed.

zemion closed this issue

2026-08-20 19:11:47 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-scheduling#5