ModerationPackage

Created by: Will, Last modification: 02 May 2008 (01:57 UTC)
This package is in Beta! It is very stable. If you decide to install and run it please contact will-at-tekimaki.com or wjames5 on IRC, we are actively debugging and will work with you to setup the package and fix any problems.


Get the Code: Checkout _bit_moderation from cvs.

Overview

The basic idea of the moderation package is to give packages a "service" for moderating various requests and a UI for interacting with those requests. The moderations package handles storing the data for the "moderation queue". Packages can add callbacks to execute when a moderation event happens so they can take required actions based on the moderation event.

The moderation package contains a "registration" system where packages can register the function they would like to use to receive moderation events when the moderation UI causes a state change on a moderation request and functions for sending the moderations package a moderation request.

moderation_id
the key for the moderation request. Packages can use this key to delete the moderation via the API.

moderator_user_id
is the ID of the moderator for the request. This is a person who may approving or denying the request. moderator_group_id is the ID of the group which can moderate the request. This is a group who may approving or denying the request.

At least one of moderator_user_id or moderator_group_id must be set. This allows moderation by a single individual or by a group as appropriate for the package.

moderator_group_id
Similar to the moderator_user_id but this gives a group access to the moderation ticket.

moderator_perm_name
Similar to the moderator_user_id and moderator_group_id, but this gives access to the moderation ticket to any user with that permission for the related content object.

source_user_id
the id of the user who generated the request and is set automatically based on the active user when the request is made to the moderation system.

status
a flag which is used to determine the status of a request in the queue. Packages can register status transitions when they register their callback.

last_status
a flag which keeps the last_status the event had. This allows packages to act different if something is say changed from "Pending" => "Approved" vs. changing from "Request Info" => "Approved" where they may want to take a different action based on the prior state. This may not HAVE to be in the database but I put it in here now for completeness. It may just be that this field is sent in the array shipped to the package when an event is sent.

content_id
the content object to which the moderation replies. Not all requests (such as membership moderation) require this so I leave off the NOTNULL requirement.

type
a flag so that a single package can have more than one queue type. For example groups needs membership and content queues which should be shown in different lists and need to be handled different by the package.

package
is designed to allow multiple packages to have the same "types" registered without them getting confused.

request and reply
This stores free form text with things like "Hey dude, want to join my group? We rock!" and "No dude! You Sux!".

These may belong more in a notifications "service" package so maybe they should be replaced with an ID from that package instead or just be included in the function call, but be triggered from here when the requestModeration call is made. This would of course lead to inter-package dependencies which the installer doesn't handle well yet but that could be fixed as well.

The UI consists of a page that lists pending moderation for a given user by package, type and status. Future ideas might possibly include a module that does the same and vanishes if there is nothing to be listed. This would possibly include links to see the request and reply messages as well as links to the state changes that are supported for the current state.

pStatuses may be expanded to be a little more complex to allow landing pages after a moderation event or something like that but I think that can be handled as a future enhancement as well.

The interface used by the package is essentially very simple and that all state changes are enforced by the moderation system. Packages can decide what to do for a given state change when they get the notification including deleting the request.

If we want to allow packages to change state on their own or list on their own it would be easy to add a getList() call and a changeState() call.

Comments

by , 19 Jan 2008 (12:59 UTC)
Some very cool abstractions there. Just be sure to rip out all of the old Articles moderation things...
  Page 1 of 1  1