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

well… at some point there has to be some voting code done for MemberDB. Namely because Linux Australia has to have elections sometime early next year, and the code really should work before then!

Currently, we can easily work out who is a current member of the organisation. Only current members, with the appropriate type of membership should be able to vote. Initially, we will assume that if member_types.validates_membership=true and member_types.revokes_membership=false, they are able to vote (i.e. if they show up in the current_memberships view).

This means they can log in. This is a good thing (note, a member may have to reset their password first – this is supported in latest MemberDB snapshots).

Once logged in, the member should be able to see a list of elections they can currently participate in. Elections (election table?) should be tied to organisation and a time period. They should also have a name and description. Only the election_id should be unique.

e.g., something like:

create table election (
        id serial unique not null,
        org_id int not null,  -- election for this org (NULL=all orgs)
        name varchar(50) not null,
        start_advertising date, -- date that we'll display in a UI that "an election is coming"
        nominations_start date,
        nominations_close date,
        advertise_candidates date, -- list the candidates from date onwards
        live_results boolean, -- results in real-time
        start_voting date, -- when voting opens
        close_voting date, -- when it closes
        show_results date, -- show results from election from this date onwards (NULL=never). This field can be updated (i.e. after the results have been verified/approved)
        description text,
        CONSTRAINT "election_pkey" PRIMARY KEY (id),
        CONSTRAINT "election_org_id_fkey" FOREIGN KEY (org_id) references orgs(id) on update restrict
);

In the future, we may want to support more than one election type – this should be safe to introduce in the future as we can add a column to election and election_vote. Currently, we’re only going to care about “first past the post” style elections. i.e. the classic “a show of hands”.

Only authorised people should be able to change any details of the election – this should be a new activity, and members granted explicit permissions to do this. We will probably need to add a “data” field to the permissions table – allowing us to have more specialised permissions (i.e. only membey X can modify election Y, and only member A can modify election B).

We need positions to elect people into.
e.g.

create table election_position (
 id serial unique not null,
 election_id int not null,
 name varchar(50) not null,
 description text,
-- FIXME: insert constraints here
);

Each election needs candidates. Candidates need to be approved (by whoever can modify the election. Since the process for approving candidates can vary, this will require human thinking logic to work out that everything is okay before they click the “approve” button).

something like:

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.
 );

We’re currently making the assumption that only members can go for positions. This seems fair and reasonable – am open to arguments against it though.

So, an election has positions and each position has candidates. Candidates have spiels, and have to be approved before they’re listed.

Each member gets one vote per election position. They can change this anytime up until the closing date (this should take care of the “oh shit, someone dropped out of the election” thing too).

create table election_vote (
    election_position_id int not null,
    member_id int not null,
    election_candidate_id int not null
-- FIXME: constraints here
);

now… all that needs to be done is a UI… and some sanity checking of the above. :)