My Status Report

[Jason Pincin <chardros@linuxkb.org>]

Greeting fellow developers - my status report for 04-04-00 and the previous few weeks is
below:

This became a long Status Report - so here's an index of what I talk about with details
below:

* Moderation, Revision Control, Voting
  - Various forms being worked on for Moderation
  - New tables and so forth to control voting
  - Temporary ideas to enable Article revisions, etc
  - Lotsa other stuff
* Seperation of DB's on Vodka
  - linuxkb == production
  - linuxkb_dev == dev.linuxkb.org:81
  - developers at home should now sync off linuxkb_dev
* Changes to Tables
  - details below
* New functions: $user->get_pref() and ->put_pref() for user pref control
  - details below



* Moderation, Moderation, Revision Control, Voting, Moderation:
Yes, moderation and it's associated forms have been my focus.  Thus far I have creatyed
/moderate.php3 and added entries to ObjectActions to support it.  I have overhauled
display_article.php3 to support the moderation views of articles, and again added several
entries to ObjectActions.  Last night I committed all the code I speak of here and below,
so it can all be found in CVS now.  You can see A LITTLE BIT by logging into dev and
clicking on the "Moderate" action item at the top now.  Nothing in the DB on dev is flagged
for moderation at the moment, so thats as much as you can see.  As I get a few more forms
finished up, I'll go in and manually set a few so we can play.  

Revision control fits into moderation and voting somewhat as well.  We talked a lot about
rev control on IRC.  We agreed that we need a temporary solution in place for now,, that
supports articles only.  I've given it some thought, and decided that just having another
table, that stored complete copies of old article versions would suffice for now...
realizing that we will be replacing it down the road... and this would be EASILY migrated
to something else.  Your thoughts welcome there.  It's something I can also impliment just
by altering ->commit().

And the other part of Moderation is voting.  For now we've decided to stay away from Voter
changes to content.  So... Dan - you don't need the "VoterEdit" form for Articles anymore -
just the Admin and Author.  Cool?  Voters will only be able to affect the tree itself,
names organization, etc etc.  I've added two tables (which are the only things not on dev
yet) for votes.  One table tracks the VoteID, the object it's affecting, and the results of
the vbote if it's succesfule.  The other table just tracks VoteID's and User Object ID's so
that people will only vote once.

* Seperation of DB's
I seperated the www and dev DB's.  To go with this Aaron has made several changes to many
things that I'm sure he'll mention in his status report.  But this means our testing now
happens independant of the production system.  functions.php3's connection function now
uses the dynamicly defined _DATABASENAME_ which is defined based on host name.  LKB
developers will want to begin syncing they're local DB's with "linuxkb_dev" on vodka.
Aaron will aid this process.  All my recent changes are reflected there, and NOT "linuxkb"
on vodka.


* Changes to tables
Very minor changes to the DB tables last week.  Added one field to Users to store
preferances (I'll metion later).  Added one field to ObjectTypes to tell whether an object
is included in moderation.  Added a new table "Comments" to store data on "Comment
Objects".  All appropriate entries into ObjectActions, ObjectProperties, etc have been made
for the Comment objects as well.  I added a few entries to ObjectProperties, set some more
global flags, etc.  


* User Preferance Functions
I figured out a good (and EASY) way to do user preferances dynamicly.  There are TWO new
functions to handle user preferances now.  $current_user->put_pref() and ->get_pref().  To
place a preferance you simply do:

$current_user->put_pref("Another Preferance for This User", "A value for this pref");

and then to get that preferance value in the future you simply:

$current_user->get_pref("Another Preferance for This User");

and the value will be returned.  The Moderation pages and re-vamped display_article page
are now using user preferances to control some elements of disply - so you can see "real
world examples" there ;).

There's one remaining bug in the preferance thing - if you do a put_pref with a NULL value
or "", it'll create problems.  By tomorrow this will be fixed, and doing a put_pref() with
a null/"" value will delete the preferance in the user's profile all-together.  To put it
back, you'll simply do another put_pref with a non-null value.  If a get_pref() is run
against a preferance that has not been set, it will also return NULL - this already
functions properly.  *IMPORTANT* The ONLY reserved set of characters for preferances is #|#
(pound pipe pound).  Preferances are stored in the User table in the field "Prefs" and #|#
is used as a preferance-value-preferance seperator.  The functions handle all that.


Fwooo.  This turned out to be a WINDED report - but I've been hard at work as you can see.
I probably missed something... and I know I didn't go into a WHOLE lot of detial,
especially on the moderation stuff - so if you have ANY QUESTIONS AT ALL about ANYTHING,
please mail the list... so everyone can benefit from the answers.

Thanks,


-- 
Jason Pincin
Linux Knowledge Base Project Leader (http://www.linuxkb.org/)
http://vodka.linuxkb.org/~chardros/