Red Queen Review Engine User Manual
|
EDITORS
Often a single person will install a program like Red Queen and then maintain the application themselves. For those who prefer to share the load of incoming Thing or Review submissions, which first need to be evaluated before being added to the database, Red Queen allows the assignment of Editors.
Editors are assigned on a per Container basis. Currently Red Queen assumes that no more than a single Editor has been assigned to a given Container. This means that when an Editor needs to be contacted because a submission has been lodged, a unique person will be contacted each time, and only that person is expected to handle the submission. The Editor for a given Container, if not explicitly assigned, is inherited from the immediate Parent Container in a manner similiar to the way in which Rating Attributes are inherited.
Default Editor Assignment
Each time a new Top-Level Container is created, the Administrator is automatically assigned as the Editor for that Container with ALL editing permissions and notification flags enabled. These permissions, which can be toggled by visiting the relevant table (as discussed below), restrict the actions an Editor can take as they go about their Editorial duties. So if you are administering Red Queen entirely by yourself you do not need to worry about Editor assignments. Each time you create a new SubContainer, the Editor (you) will be inherited from the immediate Parent Container. Only by explicitly assigning an Editor to a Container can you inhibit the inheritance feature. This is elaborated upon in the following sections. As you will see, Editors can also be assigned notification flags, governing if and when they will receive email notifications.
Creating an Editor
Before you can assign an Editor to a given Container you must first determine the numeric ID of the Member that will be the Editor, and the ID of the Container to which the Member will be assigned. To do this you can either perform a search on the Member table to locate the relevant Member record, or you can determine it by looking at the value of the member_id variable in links that include the member, such as for links leading to the Member Profile page. Likewise for the relevant Container, either do a search on the corresponding Category, Team, or Yellowpage table, or study the links which access the browsable pages for the Container.
There are 3 separate tables used for the assignment of Editors, one for each of the 3 Container Types: these are the CategoryEditor, TeamEditor, and YellowpageEditor tables. Each table has the same basic structure, but here we restrict ourselves to the CategoryEditor table for the discussion.
To assign an Editor to a Category, use the Database menu from the Database control panel to select the option to Add a record to the CategoryEditor table. The form you'll be presented with will look something like this (where some example input values have been filled in):
In the example shown above we have given the Member (with ID = 9) permission to Validate newly submitted Items, as well as Copy, Move, and Modify Items within their assigned Category (here with ID = 3). They likewise have authority to Approve, Modify, and Delete Reviews for Items in that Category. Note, however, that in this instance, the Editor has not been assigned any permission to Add, Modify, Move, or Delete Categories that stem for their assigned Category. Neither have they been given the required permission to resolve review complaints. In practice, you may or may not want to give your Editor that sort of control.
In addition to the permissions you can assign an editor, you also have control over whether they will be notified via email of new Item submissions, or new Item Review Submissions, and even notifications when Reviews are subsequently modified.
An Editor will log into the Editor section by using a URL of the following form:
http://www.mydomain.com/cgi-bin/path/to/.../redqueen/do/editor/editor.cgi
Once they have gained access to this area (which in general, should be directory-protected) any permitted action they perform will either be through the administrative browser for the Container Type to which they belong (which allows Thing and Container records to be created/modified/deleted), or it will be through the Moderate control panel (where new Things and Reviews can be validated or approved).
Local vs Global Assignments
The flags discussed above, representing permissions and notifications for a given Editor, are local, in the sense that they apply to a specific container. Another way to assign the same flags to ALL containers of a given type is to add the member to the GlobalPermissions and GlobalNotifications tables. A flag is considered set if either the global or the local flag is set. This means that if you assign an Editor a set of global Item permissions, the corresponding local Item permissions have no affect on whether a specific action can be carried out (it can). Likewise, if you assign an Editor global New Supplier Review notifications, the assignment of local New Supplier Review notification for certain YellowPages makes no difference (the Editor will be notified). In other words, local flags are really only meaningful in the absence of the corresponding global flag.
It is important to realize that unless either global or local notifications have been assigned for a given Editor (and container in the case of local notifications) NO email will be sent to the Editor. So if you think the notifications are not being delivered when they should be, check exactly what flags have been assigned to the Editor in question.
Finally, global notification is useful if the Editor wants to be treated in the same way regardless of which containers have been assigned, whereas local notification is appropriate if the Editor wishes to have a "custom" assignment of notifications for individual containers. Editors cannot assign these global and local flags, only the Administrator can do so, via the Database control panel.
Inheriting an Editor
Editor inheritance allows a Member to be assigned, as an Editor, to a given Container and assume the role of Editor for all Subcontainers that stem from that Container and which have not had a Member explicitly assigned as an Editor. If, for example, Member "Hard Hitter" is assigned as an Editor to the top level Team Critics, and no other Editor assignment has been performed, "Hard Hitter" will also be the Editor for the Teams Critics/Baseball, Critics/Baseball/East Coast, and Critics/Baseball/East Coast/New Jersey. If Member "Home Plate" is then assigned to Critics/Baseball/East Coast, "Hard Hitter" will now only be the Editor for Critics and Critics/Baseball.
To see who the currently assigned Editor is for a given Container, visit the Modify Container page reachable from the Database menu of the Database control panel. Below the form to Modify the Container you will see who is the assigned Editor (either explicitly or via inheritance).
Deleting an Editor
When you no longer need the services of a particular Editor, you should remove the corresponding Editor record from the approriate table. For instance, to delete a Category Editor, use the Database menu to select the CategoryEditor table, and select the Delete option. When you do this a Primary Key menu will pop up. Enter the ID for the Category into the box provided and hit the button marked Go to delete the Editor.
Moderating
Moderation is performed by an Editor when they visit the Moderate control panel in the Editor section and either accept or reject the submissions that have been queued since the date of submission. These are either Things submitted for consideration by Members, or they are Reviews awaiting approval. When an Editor logs into the Moderate control panel they will see pair of panels on the left side of the page that look like, depending on whether or not anything is awaiting moderation, one of the following pairs:
|
|
For the pair of menus on the right, the Editor has logged in to find that there is 1 new Supplier record that awaits evaluation, plus 4 Item Reviews, and 2 Member Reviews that are awaiting approval. Each of the record types is processed individually by clicking on the corresponding link to bring up one or more Things or Reviews to be either admitted into the database, rejected, or left as is to be moderated at a later time. The Editor is presented with the editable fields for the record, and below each record appears an extra set of form elements to enable the moderation. For an Item submission these moderation fields will look something like the following (where we suppose a Member has submitted a record for an Aluminium Bat):
| Do Nothing Approve Delete and email the reason Delete without reason |
If the Editor approves the Item, the Member who submitted it will be emailed the standard acceptance message. But if the Editor rejects the Item they can elect to modify the rejection message that is sent out--perhaps adding an explanation for the rejection. If they elect to "Delete without reason", no message will be sent.
When a Review is moderated, the moderation form elements are the same, as is the process by which a Review is accepted or rejected.
« Table of Contents | Obtain Red Queen »
Copyright © 2004 Random Mouse Software. All Rights Reserved.