| -This package is in development. The following is a rough outline
|
| +^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.^ |
|
|
| -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.
|
| +__Get the Code:__ Checkout _bit_moderation from cvs. |
|
|
| -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.
|
| +!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 queue will hold all data for requests made to the moderation system.
|
| +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_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 is the key for the moderation request. Packages can use this key to delete the moderation via the API.
|
| +__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. |
|
|
| -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 is 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 is 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 is 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 is 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 is 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.
|
| +__moderator_group_id__ |
| +Similar to the moderator_user_id but this gives a group access to the moderation ticket. |
|
|
| -package is pretty obvious and is designed to allow multiple packages to have the same "types" registered without them getting confused.
|
| +__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. |
|
|
| -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!".
|
| +__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. |
|
|
| -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.
|
| +__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. |
|
|
| -global $gModerationSystem
|
| +__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. |
|
|
| -class ModerationSystem {
|
| +__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. |
|
|
| - /**
|
| - * Request a moderation. Returns an ID for the moderation.
|
| - */
|
| - public requestModeration($pStatus, $pType, $pPackage, $pModerationUser = NULL, $pModerationGroup = NULL, $pRequest = NULL);
|
| +__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. |
|
|
| - /**
|
| - * 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);
|
| +__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!". |
|
|
| - /**
|
| - * Delete a moderation request from the queue by ID. Returns true on success.
|
| - **/
|
| - public expungeModeration($pRequestId);
|
| -}
|
| +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 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.
|
| +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.
|
|
|
| -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.
|
| +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. |
| +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. |