History of ModerationPackage
Version 2
This package is in development. The following is a rough outline
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 will handle storing the data for the "moderation queue" and will be able to make call backs to a package when a moderation event happens so they can take required actions based on the moderation event.
This requires 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.
The moderation queue will hold all data for requests made to the moderation system.
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.
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
I am debating about with myself. This would store free form text with things like "Hey dude, want to join my group? We rock!" and "No dude! You Sux!".
I think they 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 I think they should 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 would consist of a page that lists pending moderation for a given user by package, type and status and possibly 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.
Overall I think it is a relatively simple system that is generic enough to handle all kinds of moderation tasks. Notice that 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 but I view those as future expansions on this base.
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 will handle storing the data for the "moderation queue" and will be able to make call backs to a package when a moderation event happens so they can take required actions based on the moderation event.
This requires 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.
The moderation queue will hold all data for requests made to the moderation system.
<?php
'moderation_queue' => "
moderation_id I4 PRIMARY,
moderator_user_id I4,
moderator_group_id I4,
source_user_id I4 NOTNULL,
content_id I4,
status C(50) NOTNULL,
last_status C(50) NOTNULL,
type C(50) NOTNULL,
package C(100) NOTNULL,
request X,
reply X
CONSTRAINT '
, CONSTRAINT `moderation_queue_moderator_user_id` FOREIGN KEY (`moderator_user_id`) REFERENCES `".BIT_DB_PREFIX."users_users` (`user_id`)'
, CONSTRAINT `moderation_queue_moderator_group_id` FOREIGN KEY (`moderator_group_id`) REFERENCES `".BIT_DB_PREFIX."users_groups` (`group_id`)
, CONSTRAINT `moderation_queue_content_id` FOREIGN KEY (`content_id`) REFERENCES `".BIT_DB_PREFIX."liberty_content` (`content_id`)
, CONSTRAINT `moderation_queue_source_user_id` FOREIGN KEY (`source_user_id`) REFERENCES `".BIT_DB_PREFIX."users_users` (`user_id`)
'
",
?>
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.
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
I am debating about with myself. This would store free form text with things like "Hey dude, want to join my group? We rock!" and "No dude! You Sux!".
I think they 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 I think they should 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.
<?php
global $gModerationSystem
class ModerationSystem {
/**
* Request a moderation. Returns an ID for the moderation.
*/
public requestModeration($pStatus, $pType, $pPackage, $pModerationUser = NULL, $pModerationGroup = NULL, $pRequest = NULL);
/**
* Register the callback function for a given package. When status on a packages queue changes this function will be called.
* The function should have the following API:
* handleModeration($pModeration)
* Where $pModeration is an array with all of the information in the moderation_queue table.
*
* $pStatuses gives the state transition table (as an array) for the package so that the moderation UI knows how
* to display links to the transitions that a request can make.
*
* For example:
* $pStatuses = array( "Pending" -> array("Approved", "Rejected"), "Rejected" -> ("Delete"));
* This would show moderations in the queue in the "Pending" state with links to change the state to "Approved" or "Rejected".
* Moderations in the queue "Rejected" would show with a link to the "Delete" state.
*/
public registerModerationListener($pPackage, $pFunction, $pStatuses);
/**
* Delete a moderation request from the queue by ID. Returns true on success.
**/
public expungeModeration($pRequestId);
}
?>
The UI would consist of a page that lists pending moderation for a given user by package, type and status and possibly 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.
Overall I think it is a relatively simple system that is generic enough to handle all kinds of moderation tasks. Notice that 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 but I view those as future expansions on this base.