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

New Issue

zemion · 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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-scheduling#5