Elections & Voting

An Election document carries scheduling, eligibility predicates and candidates. Voter eligibility is resolved per federation level: who can vote in an FFPJP national election differs from a club AGM, and the eligibility service consults the OrgNode tree, license status, membership age and any explicit denylist. When a candidate registers, their profile and platform are stored against the election.

Voting opens at the scheduled time. Each ballot is cast through the secure online voting endpoint, anonymised by separating the voter-identity check from the ballot-storage write — the ElectionAuditLog model validator and the service-layer _sanitize_details helper both enforce ballot secrecy so even a compromised audit reader cannot reconstruct individual votes. Proxy voting is layered on top: a voter can grant a proxy to another voter, but proxy chains are blocked (A→B→C is rejected), proxies can be limited to specific positions, max_proxies_per_voter is configurable per tenant and revocations carry a structured revocation_reason.

When voting closes the count runs with quorum verification and tie-break detection; results land at GET /public/elections/{id}/results. Around the election sits the Meeting domain (PL-T104) — a state machine draft → notice_sent → in_progress → concluded → minutes_draft → awaiting_signatures → signed. Each MeetingAgendaItem can include a voting widget with simple/2-thirds/3-quarters/consensus thresholds.

MeetingMinutes are versioned, content-hashed (SHA-256) and the signed PDF is WORM-archived. Signing runs through a pluggable adapter — BankID, Freja eID (qualified electronic signature), DocuSign, Clickwrap or eIDAS Wallet — gated by the tenant's SigningConfig.allowed_providers and require_qualified_signature flag. Two scheduled jobs (meeting-reminder-dispatch, minutes-signature-expiry) keep the workflow moving, and the Freja webhook is HMAC-SHA256-validated.