Set election name from CvrExport.json ElectionId

[nealmcb]

Example:

"ElectionId": "2016 Clear Creek Primary Election",

And don't require a date, unless they give us metadata for that also.

[ranweiler]

@nealmcb I saw that ElectionId that file corresponds to a title, and agree that we should extract the election name from this in one way. There are two annoying issues here.

1. We're currently requiring that an election (as an entity), contests, and candidates are all defined prior to uploading the CVR export. This is so we can satisfy foreign key constraints in the backend database, which I would like to preserve.
2. We are using the definition of an election (via specifying a "title" and date) as the initial frontend act which creates an "election" in the backend. The subsequently uploaded election data (from the manifests) are then scoped by this election definition. So, if we remove both the title (since we'll get it from the CVR export file) and the date (because it should either be unnecessary or also derived), then we'll have to come up with a new frontend way of indicating the start of a new election.

I have a bunch of ideas about how to do this. The most straightforward is as follows: right now, we process each manifest file as it is uploaded by the user. This is why there are upload order requirements and temporarily disabled buttons. Instead, we can have the user upload each required manifest, in any order. Once the entire set of required manifests have been uploaded, we can enable a button to process them/configure the election (or can just automatically do this, checking if the set of manifests is complete as each one is uploaded.). This will remove the unnecessary frontend requirement that manifests must be uploaded in a certain order (since that is a side-effect of the processing order requirements), and we can then privately/invisibly satisfy those order/data-dependency constraints on the backend.

[nealmcb]

Yes - that's the right approach. I hope you've seen the "audit steps" we sent in as part of CORLA2, as summarized now in #57.

Take uploads, compare CVRs with the (independently-sourced) ballot manifests of ballot counts by batch and ballot style counts by county. Summarize them. Let some perhaps-clunky algorithm/scripting/backend process determine what to audit, and note that what is audited changes over time as contests become settled.

So I wouldn't sweat those parts of the front-end much at all. As described in #57, very quickly we'll want to do coordinated elections between counties, and will need a different sort of frontend which can handle 64 counties, lots of cvr files. And then, automated choosing of contests, etc. So the UI will change a lot, and I'd be fine with some ugly scripting of the backend for a while, at least in terms of election definition, while we figure the details out and discover what UI we really want on for the backend.

The frontend should focus on what an individual in a county can do with a predefined election and audit of multiple contests, helping whittle them down (settling them as they hit the risk limit) until the long tail of one tight contest.