Configuration (Candidacy)
Under “Configuration” in the left-hand menu, you will see a list of all of the configuration options available for the candidacy. Once you have created the candidacy, you will need to configure some of these options.
Locales: When you choose multiple locales, the system will allow the candidates and end users to choose the language of their frontend (display language) themselves. This also means that the system will add text fields for each locale you select. Should you use select multiple locales, you will then need to provide a translation for every editable text field in the system in each locale.
If you need more than one language, and you already have only one selected from the Summary setup, you now need to select the remaining locales.
Setting the default/fallback language of the election: If you already have all of your languages selected from the Summary setup, you should now deselect all options except the one locale you wish to have as the default/fallback language of the candidacy and click “Update Configuration.” After that, you may re-select all of the previously selected locales.
Title: This will be prefilled according to the title you have given to the candidacy in the “Summary” section. Candidates and end-users will see this title in the frontend.
Status: This is where you set the status of the election. An election can have three states: “open,” “closed,” and “scheduled.”
“Enabled” candidacy status: When a candidacy is set to “Enabled,” the candidacy site will be visible to everyone with a URL link.
“Scheduled” candidacy status: When a candidacy is set to “Scheduled,” you will need to provide a time and date for when it will be visible. When an election is set to “scheduled,” you will need to provide a time and date for when the candidacy should be visible. If set to “Scheduled,” a new section called “Schedule” will appear. Check the section Schedule for more information relevant to this status.
“Disabled” candidacy status: When a candidacy is set to “Disabled,” the candidacy site and its content will not be visible to the end-user.
Login required: if this feature is enabled, anyone visiting the candidacy site is required to sign in to gain access to the content on the site.
Session timeout: This is where you can specify the amount of minutes of inactivity an end-user session can have before it expires.
Under “Schedule,” you have the options to “Schedule enable at” and “Schedule disable at.” This section will only appear if the candidacy’s status is set as “Scheduled”.
With these options, you can set the start and end time/date at which the candidacy site will become visible/invisible. The date and time of these options are displayed as day/month/year and hour/minutes, respectively.
Under “Phases”, you can set the status of each phase of the candidacy cycle. There are six phases in Candidacy, which concern: candidate registration, candidate qualifying, publishing, recommendation, party registration, and party qualifying.
Candidate registration phase: The candidate registration phase is the period in which new candidates can be created. When this phase is inactive, users can no longer register as new candidates.
Candidate qualifying phase: The candidate qualifying phase is the period in which candidates must qualify themselves, or demonstrate that they are qualified to stand as candidates. When this phase is not active, candidates can neither edit their information.
Publishing phase: The publishing phase is the period in which candidates and parties will be viewable by end-users on the candidacy site, on a new page.
When this phase is inactive, the candidates' and parties' profiles are not made public to others in the frontend. In these cases, only the candidates themselves can see their own profiles and parties that they are affiliated to.
Recommendation phase: The recommendation phase is the period in which the candidates collect recommenders to support their candidacies. When this phase is inactive, candidates cannot request recommendations and recommenders cannot give recommendations.
The recommendation phase feature requires that Recommendations are enabled and allowed by the system – this can be set up under Recommendations.
Party registration phase: The party registration phase corresponds to the period in which new parties can be created. When this phase is inactive, users can no longer create parties.
Party qualifying phase: The party qualifying phase is the period in which a candidate can join a party. When this phase is inactive, candidates are no longer able to join any parties, and parties cannot be edited anymore.
Both party phases require that Parties are enabled and allowed by the system – this can be set up under Parties.
A phase can be set as “Enabled,” “Disabled,” or “Scheduled.” Any phase may be changed at any point during the candidacy event.
Under “Candidates”, you can choose whether candidacies need to be moderated or not by a system admin/user as well as the order in which they appear in the published list of candidates.
Moderated: When “Moderated” is selected, all candidates must explicitly be approved by a system admin/user in the backend before their candidacy is considered valid. All candidates can request approval.
However, when “Moderated“ is not selected, all candidacies created will automatically be approved and displayed.
Ordering: This allows you to choose the parameter by which candidates' profiles are ordered in the published list.
Candidates' profiles ordered by their “Positions”, are ordered either by the position claimed at the candidate creation or if candidates positions has been modified by a admin/user during editing candidates on the candidates page.
Candidates ordered “Alphabetical”, are ordered alphabetically by the “Name” in their candidate profile.
Allow reordering: When “Allow reordering“ is enabled, an end-user who is viewing the candidates list is able to change the preferred order view between positions and alphabetical. When it is disabled the end-user is not allowed to choose a viewing preference of the candidates.
Under “Groups,” you can enable and disable groups in your candidacy event. This will affect whether candidates are ordered under a group or not. *Note if this is enabled and a candidate is not subscribed to a group they will not be visible on the presentation page of the candidates.
When “Groups” is enabled, the following new functions will appear:
Candidate group assignment allows you to select how candidates can be assigned to groups. There are three ways candidates can be assigned to groups:
Choice of any group: When “Choice of any group” is enabled, candidates may choose to be assigned to any group available in the system. This means that candidates can choose to be assigned to one or more groups.
Choice of groups from identity: “Choice of groups from identity” allows candidates to still select to which group they would like to be assigned. However, they are limited in the groups they can select. These limitations are set according to their identity information.
Transfer of groups from identity: When “Transfer of groups from identity” is enabled, candidates are assigned to groups automatically through the identity information provided to the system. This also means that candidates are not able to change their assigned group.
Recommendation group assignment allows you to select how recommenders can be assigned to groups. This feature will only appear if “Recommendations” are enabled. There are two possibilities:
No association: When “No association“ is enabled, recommenders are not assigned to any group, which means that they are free to give their recommendations to any candidate.
Transfer of groups from identity: When “Transfer of groups from identity” is enabled, recommenders are assigned to groups automatically through the identity information provided to the system. This means that recommenders are not able to change their assigned group and are then only able to give recommendations to candidates within the same group.
Party group assignment allows you to select how parties can be assigned to groups. This feature will only appear if “Parties” are enabled. There are three options:
Choice of any group: “Choice of any group” means that a party can be assigned to any available group.
Choice of groups from identity: “Choice of groups from identity” allows party owners to still select which group they would like to the party to be assigned to. However, they are limited in the groups they can select. These limitations are set according to their identity information.
Transfer of groups from identity: When “Transfer of groups from identity” is enabled, parties are automatically assigned to the groups based on the identity information provided to the system. This means that the assigned group cannot be changed, and only candidates within the same group can join that party.
The party group assignment feature requires that Parties are enabled and allowed by the system – this can be set up under Parties.
Ordering: This allows you to choose the parameter by which groups are ordered in the published list. Groups can be ordered by their Date of Creation or Alphabetical.
Groups ordered by their “Date of Creation”, are ordered exactly by their date of creation, meaning that groups created first, appear first, and so on.
Groups ordered “Alphabetical”, are ordered alphabetically by the “Title” of the group.
Groups ordered by their “Positions”, are ordered either by the position claimed at the group’s creation or if the group’s position has been modified by an admin/user during editing.
Allow reordering: When “Allow reordering” is enabled, it allows the end-user to change their preferred view between “Date of creation” and Alphabetical. When it is disabled, the end-user is not allowed to choose a viewing preference for the order of groups. The default setting is whatever was set under “ordering”.
Candidate membership policy: This feature determines whether candidates can be enrolled in multiple groups or in a single group.
Party membership policy: Likewise, this feature sets whether parties can be enrolled in multiple groups or in a single one instead.
Additionally, with “Groups” enabled, a new menu item under “Structure” will appear in the left-hand menu called “Groups.” From this section, you can create groups – read more about that here.
Under “Parties”, you can enable or disable the creation of parties. Read more about Parties here.
When “Enabled” is not selected, parties cannot be created.
When “Enabled” is selected, parties can be created, candidates can join parties, and recommendations can be given to parties. In this case, additional features will also be available for setup:
Moderated: This feature determines whether parties need to be moderated or not by an admin/user. When “Moderated” is selected, all parties have to explicitly be approved by a moderator before it is considered valid. However, if “Moderated” is not enabled, then all parties created will automatically be considered valid and displayed.
Creation Policy: This feature sets those that are allowed to create new parties. Parties can either be created in the frontend and the backend or solely in the backend.
Ordering: This allows you to choose the parameter by which parties are ordered in the published list. Parties can be ordered by their Date of Creation, Positions, or Alphabetical.
Parties ordered “Alphabetical”, are ordered alphabetically by the “Name” of the party.
Parties ordered by their “Date of Creation”, are ordered exactly by their date of creation, meaning that those created first, appear first, and so on.
Parties ordered by their “Positions”, are ordered either by the position claimed at the party creation or if the party's position has been modified by an admin/user during editing.
Allow reordering: When “Allow reordering” is enabled, allows the end-user change their preferred view between “Date of creation”, “Alphabetical”, and by “Position”. When it is disabled the end-user is not allowed to choose a viewing preference of the order of groups. The default setting is whatever was set under “ordering”.
Join Policy: This feature establishes how candidates can join parties. There are three options:
Users can join a party freely, without requiring an invitation from a party owner/admin.
Users can only join a party through an invitation.
Users can only be added to a party via the back office. This means that only a system admin/user can add members to a party in the backend – in this way, party owners or admins cannot send invitations from the frontend.
Invite Policy: This feature determines who is allowed to invite new members to a party. It can be just the party owners and admins or all members.
Custom invitation message: When enabled, this feature allows inviters to specify a customised message for the invitee.