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
|