Update the tally system to handle new Ballot types more generically

[JohnMwashuma]

User story

---

Currently the tally system supports 3 ballot types and can support new ballot types but with the following constraints:

• Updating of the initial tally creation files in a particular format to take into account the new ballots.
• Refactoring the tally app to accommodate the new ballot types.

This is not the desired workflow as it is prone to human errors and a longer feedback loop between the client and the devs. That said, we need a more generic solution that can configurable per deployment and handle a variety of Ballot types without the above mentioned constraints.

Proposed solution

---

• A ElectoralRace Django model will be used to hold ElectoralRace types. This model will be populated by a configurable list of ElectoralRace types from the Django settings so that in case we have new one's, they will just be updated on deployment.
• ElectoralRace creation will upon a deployment via a Django management command executed during the deployment.
• The configurable list of ElectoralRaces will consist of:
  • type (Race Type)
  • code (Race Code)
  • ballot_name (Ballot Name). NB This should be similar to the Ballot Number column name in the sub constituency file.
• The Ballot model will be updated to have a Many to 1 relationship with the ElectoralRace model for assignment of ElectoralRaces to Ballots.
  • With this change the current race_type field on the Ballot Model will be retrieved from the ElectoralRace Model hence this field will be removed from the Ballot model.
• The SubConstituency Model will also need updating to have a Many to Many relationship with the Ballot model. This is so that a SubConstituency can be assigned more than one ballot dynamically. This then means we will do away with the following fields:
  • ballot_component
  • ballot_presidential
  • ballot_general
  • ballot_women
• Refactor the tally app to use ElectoralRace Model where it's currently using the Races Enum.
• Refactor the tally app to get sub constituency ballot types from the ballot field.

Acceptance Criteria

---

• [x] ElectoralRaces should be configurable from a config file. Django settings.
• [x] Configured ElectoralRaces should be created/updated through a deployment.

Task check list

---

• [x] Create a ElectoralRace Model with the following fields and types:
  • type = string
  • code = number
  • ballot_name = string
• [x] Create an Environment variable called ElectoralRaces which will be an Array of race type dictionaries with the following properties:
  • type
  • code
  • ballot_name
• [x] Create a create_electoral_races Django management command that will pick the current configured ElectoralRaces and create ElectoralRace objects.
• [ ] Update the tallyho ansible role to always to always run the create_electoral_races Django management command. The command can be added to this list.
• [x] Refactor the tally app to use ElectoralRace Model where it's currently using the Races Enum.
• [x] Refactor the tally app to get sub constituency ballot types from the ballot field.

[pld]

Very good, this is a long time coming, those 4 field were always a glaring red flag that we need to rearchitect. This approach makes sense to me, one suggestion: can we change Race to ElectoralRace throughout? Race ambiguous since it has multiple shared meanings, but ElectoralRace should be very clear

[JohnMwashuma]

Nice! makes sense.