Election-cycle Setup Guide

1. Authority

An association Owner or Administrator creates the cycle. Operational officers manage it only after a valid election appointment. The ability to create a cycle does not imply unrestricted authority to erase it after operational or governance activity has begun.

2. Election types

• Welfare Committee election
• Mutual Fund Committee election
• Main Executive election
• By-election
• Runoff election
• Confirmatory election
• Other election

The ordinary types are subject to harmonised annual sequencing and interval validation. Use another type only where the election genuinely falls outside the ordinary sequence.

3. Required fields

Enter title, description, unique reference, type, nomination mode, nomination dates where required, voting dates, result-approval count and permitted verification methods. The voting end must follow the start and the continuous period may not exceed 48 hours.

Self and Mixed modes require a nomination opening and closing time. Nominations must close before voting begins.

4. Status lifecycle

The current model includes Draft, Nominations open, Ready to open, Voting open, Voting closed, Tallying, Awaiting result approval, Results published, Cancelled and Invalidated. Scheduled status refresh and Commissioner actions move the election through the lifecycle.

Do not force a status directly in the database. Use the normal service actions because they freeze registers, create audit events and apply readiness checks.

5. Verification options

Select only methods the organisation can actually support. Email and SMS require reliable delivery. Passkeys require HTTPS and correct relying-party settings. Assisted verification must preserve secrecy. Member PIN depends on secure activation and storage.

6. Editing

Configuration is editable only while the election is Draft, Nominations or Ready. Voting opening freezes ballot content. Changes to nomination settings, positions, candidates or photographs may invalidate candidate-list publication and readiness.

7. Deletion, cancellation, invalidation and historical retention

A missing Delete action is normally a record-protection safeguard rather than a user-interface defect. Election cycles are parent records for appointments, positions, nominations, candidates, registers, credentials, ballots, tally snapshots, approvals, incidents, objections, complaints, declarations and audit events. Removing an established cycle can therefore destroy evidence or break historical reporting.

7.1 When permanent deletion may be considered

Permanent deletion should be restricted to a genuinely unused cycle that satisfies every applicable condition below:

• the cycle is still in Draft status;
• voting has never opened;
• no nomination has been submitted or decided;
• no candidate or position record requiring preservation depends on the cycle;
• no election-specific voter register has been certified or used;
• no one-time credential, email code, SMS code, PIN verification, passkey verification or assisted credential has been used;
• no ballot, participation marker, receipt, tally snapshot, result approval or declaration exists;
• no appointment has been activated or formally accepted for operational use;
• no objection, complaint, incident, recount or audit-dependent decision exists;
• the authorised governance user supplies a reason and confirms the election reference; and
• the server repeats all eligibility checks immediately before deletion inside a database transaction.

The interface may apply stricter checks. If the deployment has not implemented controlled unused-draft deletion, the absence of a Delete button remains the correct behaviour. Never bypass the application by deleting the row directly from Django Admin, a database client or the production shell.

7.2 Which action to use

Archive and supersede may be governance or reporting descriptions rather than model statuses in the current release. Do not manually invent a status value. Where no dedicated archive or replacement-link field exists, record the relationship in the approved reason, incident, description or institutional register and retain both cycles.

7.3 Commissioner exceptional-action procedure

The controls appear on the election detail page under Commissioner controls only for the currently appointed Commissioner and only when the present status supports the requested transition. Platform Administrators, association administrators and technical superusers do not obtain this authority merely from their administrative account; they must not substitute themselves for the appointed Commissioner.

The available actions are:

After selecting an action, enter a formal reason containing at least 20 characters. The system rechecks the state inside a database transaction, changes the status, clears publication time, creates a resolved critical incident and appends an audit event. If another process changes the election before confirmation, the action is refused rather than partially applied.

7.4 Historical presentation

A Cancelled or Invalidated election remains visible to authorised users with its terminal-status badge and formal reason. Normal operational controls are closed. This is intentional: historical retention is part of the evidence model, not a failure to tidy the dashboard.

7.5 Why a cycle may fail deletion eligibility

The system should refuse permanent deletion as soon as any electoral, voter, governance or audit-relevant activity exists. A cycle may therefore remain undeletable even when no ballot was submitted, for example because officers were appointed, nominations were received, credentials were used, a register was certified, an objection was filed or a formal decision was recorded.

8. Final review

Before handing the cycle to the Committee, verify association, reference, time zone, dates, mode, approval threshold and verification methods. Record the governance authority for the configuration. If the cycle was created in error, resolve it before appointments, nominations, register certification or voter activity begin.