WIP: Standardize handling of CVRs that provide no Precinct information

[yezr]

What Happens Now

RCTab uses vendor provided CVRs. We cannot guarantee that every CVR includes precinct identifiers.

When Tabulate by Precinct is enabled, all parsed CVRs must have a non-null precinct identifier or else tabulation halts with an error. Some CVR provider implementations put descriptive strings into the precinct identifier property (like no precinct id) to avoid tabulation halting.

The end result is that CVRs with precinct identifying information have successful result reports created. If any CVRs without precinct identifying information are present, they are all bucketed into a no_precinct_id_precinct_detailed_report, where no_precinct_id is the magic string used in that specific CVR provider implementation. Users must look in the Tabulate by Precinct folder in the output and recognize the no_precinct_id results to know that some CVRs did not have precinct identifying information.

What We'd Like To Happen

CSV providers should match the raw data as close as possible: if there are no precinct identifiers in the CSV, the CastVoteRecord.precinct_id should be null. Upstream, somewhere in the Tabulation round by round logic, CVRs without precinct identifying information should be

• flagged to the User that Tabulate by Precinct is enabled and at least some CVRs do not have precinct identifiers. Preferably with some identifying information, like the CVR file they came from or the ballot id, to investigate.
• bucketed into a no precinct id results report similar to the current output. But this should be provider agnostic and use the same "no identifier" precinct identifier, irrespective of which provider the CVR came from, for any CVR that doesn't have precinct identifying information

Open Questions

• Could this get flagged in the pre-tabulation check pop up???