Change willing choices to exact parties running in the user's constituency

[tdg]

Rather than a single list of all parties we support, first find out the user's constituency, then show them the parties that are running in their constituency that they could be willing to vote for (on behalf of someone else).

N.B. this is about modelling which parties are standing in each constituency, not which candidates are standing. The latter is tracked in #619.

See also #27 for allowing the user multiple willing choices, although that could still be done without implementing this.

Motivation

• Avoids allowing user to choose a party which they can't vote for.
• Solves the problem of not being able to allow party X in a by-election because they're not in both constituencies.
• Allows us to include minor parties WEP, NHA, etc.
• Avoids cluttering the willing list with parties like SNP, or Plaid Cymru who only stand in certain areas (although it would still clutter the preferred list).
• Open support for Northern Irish parties.

Implementation

For by-elections, we work with a YAML file that tells us the parties anyway.

For general elections, we could work with democracy club data, with some sensible fallbacks. E.g. if missing democracy club data, assume:

• any party with more than 10 members in parliament will be standing a candidate in that constituency.
• any Scottish constituency will have a nationalist candidate (SNP)
• any Welsh constituency will have a nationalist candidate (Plaid)
• any NI constituency will have a nationalist candidate ?

[tdg]

To clarify, this is the voter's WILLING options

[tdg]

Resources: https://candidates.democracyclub.org.uk/api/docs/csv/

[tdg]

This would ideally be reflected in prospective partners' profiles, so that it would be impossible to swap with someone who is incapable of voting for a given party

(Reductio ad absurdum: a partner offering to vote SNP in England)

[aspiers]

I would suggest redefining this task a bit. There are two places where the user is asked for their "willing" party, i.e. the one they are willing to tactically vote for:

1. On the home page prior to login
2. After login (see app/views/users/edit.html.haml)

We only know the user's constituency in the second of these two cases, so in the first we can't limit the choice of parties at all. This means we have to handle the possibility that the user might choose an invalid "willing" party prior to login, and we only discover it's invalid after login when we learn that this party is not standing in their constituency. So at this point we need to tell the user their choice is invalid, reset it, and ask them to choose a new one.

Similarly, if they change constituency after selecting a willing party (e.g. because they're a student and have changed their mind where they will vote) and if the new constituency invalidates their previous choice, again we have to let them know, reset the choice, and ask them to choose a new one.

Both of these scenarios can probably be handled by the same set of code changes. However this is non-trivial, because it requires adding a new many-to-many relationship between the parties model and the ons_constituencies model on the backend.

@baob Thoughts welcome.

[aspiers]

My concerns above can be addressed by asking for constituency first before asking for willing/preferred, as sugested in #625. This seems a much more elegant solution to me.

[aspiers]

I have updated the description and moved some info there which was previously misplaced in #619.

[baob]

See comments on https://github.com/swapmyvote/swapmyvote/issues/619#issuecomment-1179484454 about when this information becomes available w.r.t. the actual election date. We don't actually know for sure which parties are standing in each constituency until the SOPNs (candidate lists) are available in a usable form, though, we can make guesses based on the size of the party and what candidates stood in previous elections.