populate organisation_geography_id for gla.a elections in wizard

[symroe]

In the live database, there is no organisation_geography_id set in the elections_election table for ~18k elections.

Is this field used any more?

This normally doesn't matter, but there are 205 cases where there's also no division_geography_id attached.

I think it's impossible for these elections to be returned with a postcode search?

This is important, because the gla.a elections (2016 and 2020) are in the 205 without either geography attached, and the 2020 gla elections aren't returned with a postcode search.

1. Should the organisation_geography_id be set in all cases?
2. Should there be a check that one of (organisation_geography_id, division_geography_id) is set, per election?

[chris48s]

Some elections aren't supposed to have either a division geography or organisation geography. For example top-level groups IDs like local.2020-01-30 shouldn't have either. Are you including those in your count?

The GLA Additional ones should have a London boundary attached though. I'll have a look at those.

[symroe]

Oh yes. The ones where group_type != election without either geography ID we have:

gla.a.2016-05-05
gla.a.2020-05-07
gla.c.2016-05-05
gla.c.2020-05-07
naw.c.2016-05-05
naw.c.2018-02-06
naw.r.2016-05-05
sp.c.2016-05-05
sp.c.2019-08-29
sp.r.2016-05-05

[chris48s]

I've manually set an organisation_geography_id on gla.a.2016-05-05 and gla.a.2020-05-07

For future reference, gla.c, naw.c, naw.r, sp.c and sp.r are all group IDs for a bunch of divisions, (regions or constituencies) so they don't need an organisation_geography_id.

gla.a is unique because its a subtype Id with no divisions/ballots under it, so the subtype ID doubles up as the ballot ID.

The future work here is that when we create a gla.a ID through the wizard, the organisation_geography_id should be populated.