| 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.
|
| -
|
| -{code}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);
|
| +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);
|
| -}{/code}
|
| +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. |