[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: question? Not counted box in race editor



From: owner-support@gesn.com [mailto:owner-support@gesn.com]On Behalf Of Tari Runyan
Sent: Thursday, January 25, 2001 5:48 PM
What does this box do exactly when you check it?  and what would be an example of when you would use it?
 
Ignorantly yours,
Tari 
 
 
Good question...
 
Below is a post from our internal development list.  It is a little technical, but hopefully the gist comes across.  There are cases you want different headers for the same set of races.  Problem is that ballot styles (sic, not card styles) are determined by their unique set of races only, not headers.  The expedient solution was to create this flag to allow "placeholder races that are not really races".  You can use this flag to force a new ballot style by creating a dummy placeholder race.  You can then hang headers off of this placeholder race, like any other race, but the race won't show up on reports or the AVTS screen.
 
If this all sounds like a hack, you're right.  We'd be more than open to better solutions for Gwennett, so long as it didn't break other cases, but trust me this is a tough design nut to crack.  Well, Tab and I were not been able to find a better solution so far at least.
 
Ken
 
-----Original Message-----
From: Ken Clark [mailto:ken@gesn.com]
Sent: Thursday, April 06, 2000 4:50 PM
To: devel@gesn.com
Subject: Races that are not races

I talked to Tab about this for about an hour a week or two ago.  I'm now at implementation point though and wanted to get some details hashed out.
 
The BallotRotRaceRot table does not store headers (duh).  The GEMS design is that headers come along for the ride as decoration for a set of races.  We have a mechanism to ensure that only headers of a given vgroup pair appears on a vgroup-specific card, but you can't use a header to force a different vgroup-specific ballot.  Note I am being careful about the terms card and ballot here.
 
Gwinnett wants a different card header for absentees despite the fact that the absentee race set is identical to the polling race set.  There are a number of ways we can deal with this, but the current work around is to create a dummy race with no candidates to differentiate the ballots.  This works, but this race then gets downloaded to the AV and TS.  On the AV the race shows up in the reports.  On the TS the race ends up on the screen.  It probably shouldn't do either.  I don't think SOVC and Summary include races with no candidates, but that is more of an oversight than a design.
 
Here is what I propose:
  • New race field "DontCount".  If nonzero, the race is not downloaded to the AV, and is filtered from all reports, candidates or not.  This is a convenience field so people don't have to create special race filter sets to exclude the race.  Also makes a nice "withdraw race" flag if we like.
  • New race field "CountMethodMask".  Same as the one in Header.  The original logic was that a race on paper must by definition also be on touch.  If the race isn't counted that is not necessarily the case, and hell who knows maybe there are crazy reasons to do this with other races too.
One other possibility would be to not have the CountMethodMask race field and say that DontCount races also never appear on either an AV card or a TS screen.  If users want, they can always attach a significant header to the DontCount race if they want text to appear on the card or screen.  I'd probably call this a "PlaceHolder" race type rather than a separate DontCount flag.  This is not as general as my proposal, and means they have to go through the extra step of creating the sig header (likely with the identical name), but I am not thrilled with the idea of two new race fields either.  Let me know if you like this better, or have other ideas.
 
I am moving forward with this because MN is going to need to be able to force separate card ids just like Gwinnette, only this time its so we can do the high-order precinct id bit trick for absentees without header cards.
 
Ken