previously, we had the idea of an election candidate:

create table election_candidate (
     id serial unique not null,
     election_position_id int not null,
     approved boolean,
     member_id int not null,
     spiel text,
        CONSTRAINT "election_candidate_pkey" PRIMARY KEY (id),
        CONSTRAINT "election_candidate_election_position_id_fkey" FOREIGN KEY (org_id) references election_position(id) on update restrict,
      CONSTRAINT "election_candidate_member_id" FOREIGN KEY (member-id) references current_memberships(id)
 -- FIXME: need constraint that member is a member of the correct org.
 );

now, that’s all fine and good… but we need the whole nominations thing to work.

so what about something like this:

create table election_candidate_nomination (
     when timestamp not null default now(),
     election_position_id int not null,
     from_member_id int not null, -- member doing the nominating
     for_member_id int not null, -- the member being nominated,
     reason text,
     CONSTRAINT "nomination_from_member_id_fkey" FOREIGN KEY (from_member_id) references members(id) on update restrict,
     CONSTRAINT "nomination_for_member_id_fkey" FOREIGN KEY (for_member_id) references members(id) on update restrict,
     CONSTRAINT "election_candidate_election_position_id_fkey" FOREIGN KEY (org_id) references election_position(id) on update restrict,

);

this should be adequate to keep track of nominations. When enough nominations are gathered and the candidate accepts, then we can create an entry in election_candidate.

okay…. my previous ramblings on the details of the voting stuff (see MemberDB Voting code (planning… in some sense of the word)) didn’t really address how someone nominates someone else and how they accept/deny the nomination.

Member A nominates member B for position P.
Member C seconds the nomination for member B for position P.
(there doesn’t need to be a distinction between nominate and second – indeed we could just allow up to n nominations – or should it be a preference?)
Member B either accepts or refuses the nomination

If the nomination is refused by member B, that’s final (for that position).

If the nomination is accepted, we no longer need to allow further nominations of B for P.

When the nominations period is over and the show candidates period begins, we just display those nominated who have enough nominations (i.e. been seconded).

When it comes time to vote, those people are on the ballot.

Admins can, of course, dick with this as much as they want.

Yes, admins can screw with the results of the election – we are root, hear us roar.

At least it’s a bit more secure than some elections.

I’ve been making inroads into the voting part of MemberDB.

You can create an election (with a number of positions), list elections, and view extra details about it.

It handles the priviliged versus non-priviliged user thing and I’m getting to work on the nominations part.

I’ve made a bunch of infrastructure changes too. A bunch of stuff in the forms code has made things easier – I have no idea how i’d do all of this without that as a base (okay, i’d probably go and write it).

I’m basically spending this week on the voting stuff, and being this far in atm seems to be on track. I guess i’ll see as time goes on.

PEAR :: Bug #2417 :: [PATCH] Incorrect processing of ‘permission denied’ style error messages

Got the bugger – and supplied a patch that fixes it!

This should spell an end to those annoying (and really unhelpful) “DB Error: unknown error” messages from PEAR::DB when the user doesn’t have enough permissions.

Been hitting this a bit with MemberDB.

I’d love PEAR::DB to return back the native error string as well… but it’s kinda hidden.

Maybe I should be changing the getMessage() methods to return the PEAR message *and* the extra debug stuff? hrrmmm…

oh well, for later