Submission Manager is an online system for accepting and managing submissions to a literary magazine. It is a web-based front end to a mySQL database.
The basic elements of the system are:
Contacts:
All contacts are stored in a single database table. This means that contact information about your staff is stored in the same place as information about your submitters. What differentiates staff from submitters is their level of access to the administrative parts of the system. This is called their access level.
Submissions:
Submissions are the work submitted by contacts to be considered by the publication. Each submission has a record in the database that contains all of the information about the submitted file (the author, title, etc). This record is linked to the submission document, which is stored on the publication's server. The submission document can be any kind of document, but Submission Manager recommends that contacts submit files in Rich Text Format (.rtf).
Actions:
Actions are records of processes created by a staff member on a submission. There are 4 types of actions:
| Accept: | Accepting a submission for publication. |
| Withdraw: | Withdrawing a submission from consideration. |
| Forward: | Passing a submission from one staff member to another. The system is designed with 4 different types of forward actions. These are fully customizable. |
| Reject: | Rejecting a submission. The system is designed with 4 different types of rejects. These are fully customizable. |
Submission Manager allows various
contacts (editors, submitters, etc) to
submit a document containing their work. Certain contacts can then create
actions (accept, withdraw, forward, reject) for submissions already entered into the system. Submission Manager also allows administrators and editors to view all submissions in the system, to assign them to a reader, and to see the current status of a submission.
One other concept that is very important to understand is access levels. Each contact in the database is assigned an access level when their record is created.
The access level places them into a group of contacts who have the same level of administrative access to the system. Access levels determine whether or not a group of contacts can access the administrative area of the system, and whether or not they can perform specific actions on the system.
The system is designed with 8 access levels. 3 are hard-coded, 5 are customizable. The access levels are:
| NULL: | Contacts with a null access level have no administrative access to the system. This level is designed for submitters. Contacts with a null access level can submit stories, and check on their account, but that is all. The default access level is null. |
| admin: | Contacts with Admin level access have complete administrative access to the system. They can configure exactly how the system works, and can change how the system's appearance. They can view all submissions and can perform all actions on them. Admin users can set and change the access levels of all contacts. Because admin users have the power to change all aspects of the system, only very trusted contacts should be given admin level access. |
| editor: | Editors have access to some administrative areas. They can view all submissions and can perform all actions on them. Editors can also change the access level of contacts who are not admins; however, they cannot make anyone an admin, nor can they demote an admin to another access level. Editors do not have access to the configuration areas. This level is designed for staff members who will assign submissions to other staff members. |
| active 1-5: | These are 5 customizable levels of access to the system. Admins and editors can use these levels to group staff members by the types of actions they are allowed to perform. For example: active 1 can be used for a group of readers who can forward a story to another reader, but not reject it or accept it. Active 2 can be used for readers who can reject stories, but not accept them. And active 3 can be used for readers who can perform all actions. |
| inactive: | This level is used for a contact that was formerly on staff, but no longer has access to the system. (for example: A former editor) |
For staff members, access level is determined by the admins in the contacts area. When a submitter creates an account, their access level will always be NULL.
- The system assumes that only one staff member will be reading a submission at one time. This will be very important when customizing the system to your editorial process.
- The status of a submission is always determined by the last action performed on that submission.
- Web server
- PHP (version 4.1 or higher) with MySQL support.
- MySQL (version 4.1 or higher)
- SMTP application (if you want the system to send email notifications)
- Web Browser
Submissions Manager is designed to be accessed by a web browser. It has been tested on a wide variety of current browsers including Internet Explorer 6.x, Firefox (any version), and Safari 2.x. Some features may not work on earlier versions of these browsers, but newer versions of all of these browsers are freely available.
Submission Manager requires that a user's browser be set to accept cookies, and to allow popup windows. Some popular browsers do not do either of these by default. Staff members can change these defaults in the browser settings. For information on how to do this, refer to the browser's documentation.
- Create a directory on your server where Submission Manager will be stored: (for example: http://www.example.com/submissions).
Important: This installation directory must be readable and writeable to the web server. Refer to your server's documentation for help with changing read/write permissions.
- Create a MySQL database. Submission Manager does not create the MySQL database for you. Before you begin installation, you should create an empty named database (for example: submgr). If you have databases on the server for other uses, it is recommend that you create a separate database for Submission Manager.
- Know your MySQL user information. You will need to know your MySQL host name, and know the username and password of a MySQL user who has full read and write privileges to your server.
- Know the first name, last name, email address, and password of the first admin level contact you would like to create (the person who will do the initial configuration of the system). The password must be 6 characters long and can only contain numbers and letters.
To install Submission Manager on your server unzip and upload all files to the directory you created prior to installation (for example:
http://www.example.com/submissions).
The rest of the installation process is done using a web browser. To start the process, type the exact URL of the installation directory (for example:
http://www.example.com/submissions) into your web browser's address bar and hit return. You will be lead through a 5-step installation process.
Step 1: Database connection
Submission Manager needs to be told how to connect to your MySQL database server. You will be asked for your MySQL host name, MySQL username, and MySQL password.
Step 2: Database Name
Submission Manager will ask you for the name of the database you intend to use to store Submission Manager data. This is the database you created prior to installation (submgr).
Step 3: Table Creation
Submission Manager will create the necessary tables in the database named in step 2. It will also enter default information into some of the tables.
Step 4: Admin Account Creation
Submission Manager will now ask you to set up one admin contact to configure the program. More staff accounts can be set up later. To create this admin user you will need to input the first name, last name, email address and password for this contact.
Step 5: Configuration
Admin Login: You will be asked to log in to the account you just created to configure the system.
Some of the configuration options listed below are required. The system will be accessible only to admin level users until the required options are set. Required options are marked by a red asterisk. A notice will appear on the top every page until all of these options are set.
| | * = required field |
| system_online: | This option allows you to decide who has access to the system at any given time. Your choices are:
all: This gives access to the system to everyone including staff and submitters.
no submissions: This gives access to everyone (staff and submitters) however no submissions are accepted. This is designed for the times that you want staff to be able to read submissions and perform actions but when you do not want to receive any new submissions. This might be used if your reading period has ended, but you still have submissions on the system that need to be decided upon.
admin only: This gives access to admin level users only. |
| offline_text: | This text will appear to anyone who visits Submission Manager when the system is offline. (HTML allowed) |
| instruction_text: | This text will appear on the home page above the submission form. (HTML allowed) |
| submission_text: | This is the text that is displayed in the browser immediately after a contact submits a document and is sent to the contact in their confirmation email. |
| test_mode: | Use this when testing the system. Administrators can test different actions, but no emails will be sent to contacts. When you are working in test mode, the phrase "test mode" will appear in brackets above the name of your publication. |
| timezone: | Choose your local time zone. All dates and times are stored in the database as GMT, but this setting controls how users see these dates and times. |
| dst: | Check this box if Daylight Saving Time is used in your locale. Submission Manager uses your web server's interpretation of daylight savings time (DST). This means that if your web server is in a locale that recognizes DST differently than your locale, your times may be off by one hour during DST. |
| * company_name: | Fill in your company name here. |
| show_company_name: | Checking this will display your company name (as listed above) in the upper left corner of the screen on all pages of Submission Manager. |
| logo_path: | Fill in the server path to your company's logo graphic (.gif or .jpeg) for it to appear in the upper left hand corner. The logo can appear in addition to the company name or instead of the company name. |
| * app_url: | The absolute URL to your installation of Submission Manager. (http://www.example.com/submissions/). |
| fonts: | A comma separated list of fonts to use. Browsers will use the first font available on a user's computer. |
| color_background: | The color of the background of the page. The default for this area is white. |
| color_foreground: | The color of the area around the forms. The default for this is a light grey. |
| color_form: | The color that appears inside of the form fields. The default for this is a darker grey. |
| color_text: | The color of the text. |
| color_link: | The color of text that is a link. |
| color_link_hover: | The color that link text will change to if a user hovers their mouse over that link text. |
| color_link_active: | The color of a link as you are clicking on it. |
| color_link_visited: | The color of a visited link. |
| max_file_size: | Use this to set the maximum file size you will allow a submitter to upload. This should be entered in bytes; the default is 512000 (500 KB). A setting of 0 means no limit. |
| max_comments_size: | Use this to set the maximum character length for the comments filled in the submission form. The default is 3000. A setting of 0 means no limit. |
| submission_limit: | This is the number of outstanding submissions you would like any individual contact to be able to have on the system at once. The default is 3. Setting this to 0 will allow an unlimited number of submissions. |
| pagination_limit: | This determines how many records per page are displayed when the staff is reviewing submission and contact records. A setting of 0 means no limit. |
| * upload_path: | Fill in the absolute server path to the directory where you want all of your submission files to be stored. For security reasons, it is strongly suggested that this be a non-public directory, stored somewhere outside of your server's document root. Files will be stored in this directory in sub-directories by year. This directory must be readable and writable by your web server. |
| * general_dnr_email: | All automatically generated email notifications (both submission confirmations and non-personal rejections) will come from this address. |
| * admin_email: | The main system administrative email address. The system will display this to submitters if there is a system error. This should be the email address of your web master or of someone familiar with the system setup. |
| send_mail_staff: | If this box is checked, the system will send email notifications of all submissions and all actions to selected staff members. Whether or not a staff member receives these emails is determined in their record in the contacts area. |
| send_mail_contact: | When this is checked, a submitter will receive a submission confirmation email. |
| use_genres: | This turns on and off the genre management system. If your publication only accepts one genre you probably do not need the genre management system. Otherwise, this will allow you to control which genres the system recognizes. |
| allow_withdraw: | When this is checked, submitters will have the option of withdrawing their own submissions from consideration. Submitters will only be able to withdraw submissions that have a status of "received". |
Once you fill in all of this information, click "update" and log out. The system will now be ready to accept submissions. Admins can use the buttons on the bottom of this form at any time to update the configuration information, to reset to the last saved configuration, or to reset to the system defaults.
You will want to configure actions and do some testing before you go live.
If you need to reinstall Submission Manager:
If you are reinstalling Submission Manager for any reason, know that it will overwrite existing tables with the same name, and all data will be lost. Be sure to backup any data before reinstalling the program.
If your mySQL configuration changes after you have installed Submission Manager:
If your mySQL configuration changes after your have installed the Submission Manager, you can update your mySQL connection parameters by editing the file config_db.php located in the directory where you installed the application. The config_db.php is a plain text file which looks like this:
<?php
$config_db = array(
'host' => '{host}',
'username' => '{username}',
'password' => '{password}',
'name' => '{name}'
);
define('INSTALLED', true);
?>
Update the {host}, {username}, {password} and {name} to match your mySQL connection parameters. The {name} field is the name of the database where you are storing Submission Manager data. Be sure to use a plain ASCII text editor when editing this file (like Windows Notepad). When you have finished editing the file upload it to your web server in the directory where you installed Submission Manager.
You should now point your browser to the directory where Submission Manager is installed. (for example:
http://www.example.com/submissions) This page should now contain the form a submitter will see when they enter the system.
To understand this process, take some time to make a few test submissions.
Important Note: If you want to be able to easily remove test contacts and submissions make sure that all test contacts have email addresses that end in @example.com (for example: sally123@example.com). A function included in the maintenance area will allow you to delete all contacts and submissions that come from example.com.
To create a submission, a contact must first enter all of their data, and then use the "choose file" button to find their submission file on their computer. When they hit enter, they will be asked to review their data. If their email address is already in the system, they will be prompted to log in to their existing account.
Contacts will now be given an opportunity to review their submission information. If they decide it is okay, they can click on "continue" and their submission will be entered into the system and their account will be created.
Submission Notes:
• All submissions are expected to be one document.
• The system expects that multiple titles submitted as a single document be entered into the title field separated by commas.
Submitters can log back in to their account at any time using the email address and password they entered during their initial submission. When a submitter logs back in, they will see their contact information and their submission history with each submission's status (received, accepted, declined). From this page, they can create another submission or update their contact information.
The "Need Help" Page:
Below the login form is a link to a "need help" page which answers the following questions:
- Why log in?
- Do I need to set up an account?
- How do I access my account?
- What if I forget my password?
- What if I still need help?
This page also contains a form by which a contact can have their password sent to the email address that was used to create their account.
Submission Manager has five areas to be used by staff members to configure the system and perform actions. Some of these areas are accessible to admins only, some to admins and editors, and some to all staff members. The access a staff member has to these areas is determined by their access level. The five areas are:
| Submissions: | Admins and editors have complete access to this area. Other staff members have limited access. |
| Contacts: | Admins have complete access to this area. Editors have limited access. |
| Reports: | Admins and editors have complete access to this area. Other staff members have no access. |
| Configuration: | This area is for admins only. |
| Maintenance: | This area is for admins only. |
The submission area is where submission management takes place. Admins and editors can see all submissions on the system from this window.
When an admin or editor first logs into their account, they will be taken to the submission area, which will be blank. Admins and editors must always select the submissions they wish to see.
To do this they should use the form on the upper left hand corner. There are two different ways to use this form.
Searching by ID #: If the staff member knows the Submission ID number, they should enter that into the "find submission ID:" box, and click "search submissions". The submission with the ID number they chose will appear below.
Filtering by other criteria: If a staff member is looking for a larger group of submissions, or if they do not know the Submission ID number, they should use the four fields beneath the ID box as follows:
| or show me: | This filed allows staff to filter submissions by genre. A staff member can choose to look at all submissions, or can look at submissions of only one genre. |
| whose last action: | This field allows the staff to further filter submissions by the last action performed on them. To see all unforwarded submissions, a user should select "no action". |
| to: | This field allows staff members to further filter the records by who a submission was last forwarded to (this is the staff member who currently has the submission in their queue). This field is active only when the "whose last action" field is set to any of the forwards. |
| sort results by: | This field allows the staff to sort the selected records by date in either ascending or descending order. |
These four fields are designed to logically allow a staff member to find any group of submission records on the system.
Example 1: A staff member is looking for poetry submissions that were last forwarded to staff member Mary Smith using Forward 1:
| find submission ID: |
| or show me: |
| whose last action: |
| to: |
Example 2: A staff member is looking for all unforwarded submissions:
| find submission ID: |
| or show me: |
| whose last action: |
The selected submissions will be listed in a table along with the following information:
| ID#: | The unique number of the submission assigned by the system |
| date / time: | The exact time the submission was entered |
| writer: | The name of the writer. If the name of the writer appears in red, it means that the writer name is different from the contact name. This indicates a submission that has come from a writer using a pseudonym, or a submission that has come from an agent. Hovering over the writers name will reveal their email address and name and address if available. Clicking on the writers name will show all submissions by that writer. |
| title(s): | The title (or titles) of the submission |
| genre: | The type of submission (the system defaults are poetry, fiction, nonfiction, other. These can be changed in the genre configuration area) |
| file: | A link to the submitted file. The name of the file will be the unique id number, followed by the document extension (.rft). Clicking on this link will prompt the staff member to either open or save the document. |
| comments (by submitter): | If the writer has submitted comments, the word "view" will be present. Hovering over the word view will show these comments. Clicking on the word view will open the comments in a popup window. |
| notes (by staff): | Notes by the staff made about the submission, not about the contact. Hovering over the word view will show these comments. Clicking on the word view will open the note in a popup window. |
| status: | The current status of the submission. System defaults can be used or it can be cusomized by action type. The default status levels are as follows:
Accepted: For all accepted submissions.
Declined: For all rejected submissions.
Withdrawn: For all withdrawn submissions.
Received: For all other submissions.
For information on customizing this field, click here. |
| actions: | The number of actions that have been taken on a submission. Clicking on this number allows the staff member to view the action list of that submission. |
| tag: | Admins and editors can use this to perform the same action on multiple submissions. |
Viewing a submission:
To view a submission, the staff member should click on the file name. Depending on how their browser is configured, the submission will either appear in the user's browser window, or they will be prompted to save the document to their computer.
Performing one action on one submission:
To perform an action on one submission, a staff member should click on either the number in the action column or on the submission ID #. All actions that have been created for this submission will now be displayed.
To create a new action, the staff member should click on "insert new action". The create action form will be displayed.
Let's say they are forwarding this story to a reader.
- They will fill in the action type (forward 1).
- Then select which staff member they would like to forward the submission to.
- They will also have the option of making notes about the action (in the notes box.). These notes are only for the staff to see.
- And they can fill in a message that will be sent in the email to the receiver.
- Once they think they have the action as they want it, they should click preview. All of the details of the action will be displayed in the preview area to the right of the form.
- If the action is correct, they can click send and the action will be created.
Accepts, withdrawals, and rejects work in the same way, but for these actions the "to" field will be greyed out.
Performing one action on many submissions:
Admins and editors can also perform the same action on multiple submissions. To do this, the staff member should click the tag box for all submissions on which they want to perform the same action.
Using the action box on the upper right hand corner, the staff member can select the action type, and for forwards, the receiver.
Clicking on "apply to tagged" will bring up a confirmation page that lists the action type, the receiver, and all of the submissions that will have this action performed on them. Hovering over the action name will display the email text that will be sent to the receiver(s). If everything looks correct, the staff member should hit confirm and the actions will be created.
Access to this area by Staff Members with Access Levels 1-5:
Staff members with access levels 1-5 can perform actions as described above with 3 exceptions:
- They can only see submissions forwarded to them and any other submissions made by a submitter in their assigned list.
- They can only perform the actions allowed by their access level.
- They can only perform one action at a time. (The tag field will not be visible to them).
This area is accessible to admins and editors only. When an administrator or editor first enters the contact area, the contact list will be empty. Just like in the submission area, staff members must select the records they are interested in seeing.
To do this a staff member should use the fields on the upper left hand corner.
The first field allows staff members to select which type of contacts they would like to see. They can choose "any contact" (which will show contacts will all access levels), "any non-staff" which will show contacts that have a null access level, "any staff" which will show all contacts with any access level other than null, or they can choose to see contacts of a specific access level.
The staff member can choose to further narrow their search by using the next two fields. They should then choose which field they would like to look at (ie: lastname) and then fill in the information they are looking for in the box below. The user can search for fields that either contain the text that they typed or that are an exact match for the text that they type. If they are searching for fields that contain some specific text, they should use % as wildcards.
Example 1: If the staff member is looking for a contact whose email address they know is joe@example.com, they will select:
Example 2: If the staff member is looking for all submitters who have an email address from AOL.com, they will select:
| show me: |
| whose: |
| contains: |
Example 3: If the staff member is looking for other staff members whose last name begins with b, they would select:
| show me: |
| whose: |
| contains: |
(the search is not case sensitive so b% will yield the same result.)
To see all contacts, the staff member should search for any contact and leave the field empty.
When the search is complete a list will be displayed of contacts matching the search criteria. The list will contain the contact's unique id number, their name, email (a mail to link), and access level. The list will be sorted by whatever field the staff member chose to search by in ascending order.
Hovering over the contact's name will show you that contact's name, email address, and full mailing address.
Seeing a complete contact record, editing or deleting a contact:
To see or edit a contact record, a staff member should click on the name or the contact id. The chosen contact will be displayed in full on the right hand side. The staff member will now be able to see and edit the contact's password, their access level, whether or not they receive administrative emails, notes about them, and how many submissions they have on the system.
Editing basic information: To edit a contact's name and address information, the staff member should simply type the new information over the old and hit update. Old information will not be saved. To keep older information, use the notes box.
Setting the access level of a contact: The access level of a contact is set in the access level field. Admins can change the access level of all contacts. Editors can change the access levels of contacts who are not admins. Editors cannot create an admin level contact, nor can they delete or demote them. To change an access level, the staff member can simply select the new access level and hit update.
Deciding whether or not a staff member receives system notification emails: The contact form also contains two checkboxes that determine whether or not a staff member will receive notification of each submission and action entered into the system. These checkboxes will not be active for contacts with a null access level.
Deleting a contact: The delete button will delete a contact from the system. When a staff member deletes a contact, they will be asked whether or not they also want to delete any submissions or actions related to this contact.
Adding staff members to the system:
Admin level users and editors can add contacts to the table and assign their access level. This is done by clicking on "insert a new contact" and filling in the form.
The minimum amount of information needed to create a staff contact is first name, last name, email and password.
To create staff members, the admin or editor must select an access level of 1-5, admin, or editor. Access Levels are described in the overview section of this document. Editors cannot create an admin level user.
Before testing the system you should create a few staff accounts.
Submission Manager comes with 4 standard reports. These are designed to give admins and editors an overview of the data on the system. The reports are:
| Submissions by month: | This report shows a count of all submissions by genre by month. |
| Submissions by status: | This report shows a count of all submissions by their current status. Clicking on any count will show a complete list of all of the submissions that make up this count. |
| Forwards by staff: | This report shows a count of submissions that are forwarded to each staff member. Counts are broken down by genre and by the type of forward. In this report, staff members are sorted first by access level, and then by last name. Clicking on any count will show a complete list of all of the submissions that make up this count. |
| Contacts by access: | This report shows a count of all contacts broken down by access level. Clicking on any count will show a complete list of all of the contacts that make up this count. |
The configuration is accessible only to admins. It has three sub-areas. The administrator can move between them using the menu on the left. The three sub-areas are:
general configuration: This page allows the administrator to adjust the configuration of the system, as described in the
configuration options section of this document.
action types: This is where the administrator will customize the actions. The system is designed with 10 action types. All 10 action types are customizable. For the system to work you do not need to use all 10 action types.
| accept: | Use this to accept a submission for publication. |
| withdraw: | Use this to withdraw a submission from consideration. |
| forward 1 - 4: | Use these to forward a submission to someone else on your staff. More information about configuring forwards can be found in the "Configuring the system for your publication" section. |
| reject 1 - 4: | Use these to reject a submission. Publications can use these four levels of rejects to create standard rejection notices that range from more to less encouraging. Rejections can be configured to be form letters, or to allow room for personal comments. |
All actions have a list of variables. Some that are configurable, and some that are hard coded. The variables are as follows:
| action type ID: | This is hardcoded and used by the system to identify the action. |
| action name: | This is hardcoded and used by the system to identify the action. |
| description: | A 10-character field to describe the action to your staff. for example: Reject1 can be described as "standard", reject 2 as "nice", reject 3 as "very nice" and reject 4 as "personal". |
| status: | A field that will control what is displayed as the status of submissions. When this is null, the default status (Accepted, Declined, Withdrawn, Received) will appear. When filled in, this field will appear in the status column seen by both editors and submitters. |
| active: | When this box is checked this action will be active on your system. If you only want to have one type of rejection, you would deselect the active box on rejects 2-4. |
| access groups: | Use this field to decide which access groups can perform this action. For instance, if you have decided that readers in access group 3 will have the power to reject stories, you will select group 3 for all levels of reject. If readers in access group 2 cannot reject, deselect group 2 for all rejections. |
| email from reader: | If you check this box, the email will have the return address of the staff member that created this action instead of the general dnr email address. This means that if the submitter hits reply to this email, the staff member who created the action will get the reply. This option should be used sparingly. If it is not checked, the email will be from the email address chosen in the "general dnr email" field in the configuration area. |
| email subject: | This is the template for the subject line of the email that will be sent to the receiver when this action is performed. |
| email body: | This is the template for the body of the email that will be sent to the receiver when the action is performed. Note: When creating the email subject and body you can use placeholders to fill in information contained in the database. (for example: the name of the submitter or submission). A legend explaining the placeholders is on the left side of the page. For example, if you would like the title of the submitted story to appear in the email that is sent with any given action, you can simply type "[title]" where you want the title to appear in the text. |
genres: Submission Manager comes preconfigured with 3 genres: poetry, fiction, and nonfiction. To add new genres, type the genre name in the new field and click update. Genres can be deactivated using the checkbox to the right. Genres cannot be deleted.
If you turn off genres on the configuration page, this area will still appear, but will not affect how the system runs.
The maintenance page stores processes for managing the data on the system. Currently it has four functions.
Cleanup Temp Files:
Typically there is a one to one relationship between database submission records and uploaded files.
Due to lost connections and server glitches there are sometimes submission records without a corresponding submission file and submission files without a corresponding record. We'll call these orphaned records and files.
The Cleanup Temp files function allows you to delete these orphaned files from your system. Selecting cleanup temp files will produce a table that lists a complete count of records and files by year, and shows all unrecorded files (files without matching database records) and missing files (database records without matching files).
Clicking on the name of an unrecorded file will display the file that is missing its record. Clicking on a missing file will show the submission record that is missing its corresponding file. You can delete orphaned files by clicking
delete temp files.
Important Note: Temp files are
always created during the submission process. They are created as soon as a submitter selects the file from their computer and retain the temporary name until the submission is complete. It is therefore safest to make sure that all temp files that you delete are at least a few hours old.
Sample Data:
In order to test the system you'll need a set of dummy submissions to work with. Clicking
insert sample data will create 100 dummy contacts, submissions and files to test the system. Clicking
delete sample data will delete all of those dummy records. All sample contact records will have an email with the domain name of
@example.com. (for example:
sally123@example.com).
Export Data:
This function will allow you to export the contact data to a .csv file. This format is easily read by other database applications.
When exporting data you have four options:
| include primary key field: | When this is checked, the Submission Manager contact id will be included in the export. |
| include staff contacts: | When this is checked, staff contacts will be included in the export. |
| insert field names as first row: | When this is checked, the first row of the export will be the names of the fields. |
| use CLMP data structure: | When this is checked, the field names will be the same as the field names in the CLMP fulfillment template. This will make it easier to merge these records for mailing or other uses. We do not, however, recommend you import this data into the current CLMP fulfillment template. |
You can select the records to be exported in three ways. You can use a range of primary keys (the default is to select all records), you can select all records created after a certain date, or you can select all records modified after a certain date.
Update Data Structure:
This function has been put into place to allow administrators to easily update Submission Manager when future versions become available. Detailed instructions for using this function will be sent with any new versions of Submission Manager.
Every submission process is different; Submission Manager was designed to be flexible enough to work with most systems, but simple enough to prevent configuration from getting too complicated.
Once the system is installed and the basic configuration has been completed, an editor should go into the system and configure it for their publication. Editors should be sure to look at the following:
The system comes with 3 genres: fiction, nonfiction, and poetry.
If your magazine does not accept all 3 genres, uncheck the active box next to the genre name. To add a genre, type the genre name into the new box and click update. Editors can add as many genres as needed.
Contacts are assigned an access level in their contact record. This access level determines which actions they can perform and what type of access they have to the system.
Once again, Admin level access gives a contact the ability to fully configure the system and to perform all actions. Editor level access gives a contact the ability to perform all actions and view all submissions.
The remaining 5 access levels are designed to give lower level editors and readers access to different actions.
Access Levels are given access to an action on the action configuration page.
Let's say that LitMagA has a group of staff members that they would like to only be able to forward stories to other readers. They do not want these staff members to be able to accept or reject a submission. The editors of LitMagA decide to group these staff members into the "active 1" access level. To do this, the editor will go into each of these staff member's contact record and select "active 1" in the access field.
LitMagA has a second set of staff members who they would like to be able to reject stories as well as forward them. The editors of LitMagA decide to group these staff members into the "active 2" access level. To do this the editor will go into each of these staff member's contact record and select "active 2" in the access field.
To complete the configuration, the editors would then go to the action section of the configuration page and deselect access group 1 from all actions except for forwards, and deselect access group 2 from accept and withdrawal.
Action configuration is detailed
here.
Some notes:
To see how you can customize the email templates, see the sample rejections on the action page.
| reject 1: | uses only one placeholder - the name of your company in the subject of the email |
| reject 2: | inserts the writer's name, the title of the story, and the company name into the body of the email |
| reject 3: | inserts the same fields as reject 2, and allows the staff member to insert a message to the submitter |
| reject 4: | is a completely personal email. It uses no form language, but simply allows the staff member to compose their own email text. |
Most likely, your submission process is hierarchical. Each submission moves from a less experienced editor to a more experienced editor. Keep the hierarchy in mind as you work on configuring your system.
Also keep in mind the two important system notes:
- The system assumes that only one editor will have access to a submission at one time. Note: If there is a point where more than one editor may need to read a story at one time, you may want to create a dummy contact (finalreview@example.com) whose log in information will be shared by a group of editors.
- The status of a submission is always determined by the most recent action performed on that submission.
The key to making the system work for you is configuring the 4 forwards. Forwards are how a submission moves from one editor to another. You can assign each forward a specific meaning.
It is probably easiest to understand this using an example.
LitMagA's submission process:
Every submission to LitmagA must be read by two readers before it is rejected.
The managing editor assigns each submission to the genre editor.
The genre editor assigns each submission to a slush reader who either recommends yes or no.
All submissions that are recommended yes get sent back to the genre editor who decides whether or not that submission makes it to the final conference.
If the slush readers recommends no it goes on to a second reader for a second read.
If the second readers recommends yes, the submission goes back to the genre editor, who decides if the submission makes it to a final conference. If the second reader confirms the no, the genre editor rejects the story.
How LitmagA uses the 4 Forwards:
| forward 1: | Assign to reader |
| forward 2: | Recommend reject |
| forward 3: | Confirm reject |
| forward 4: | Recommend accept |
How a submission moves through LitMagA's system:
- The Editor assigns the submission to a genre editor using Forward 1
- The Genre Editor assigns the submission to a slush reader using Forward 1
- The Slush Reader recommends the story be rejected using Forward 2 or accepted using Forward 4. The Slush reader uses these forwards to send the story back to the Genre Editor.
- The Genre Editor uses the administrative tool to assign all Forward 2s to a second level reader. To do this he uses Forward 1 (assign) again.
- The Second Level Reader either confirms that the story should be rejected using Forward 3 or recommends it should be accepted using Forward 4. He uses these to send the story back to the genre editor.
- The Genre editor reviews all forward 3s and does a mass rejection of all submissions.
- At this point, all recommended accepted stories will have a status of Forward 4. The genre editor reviews all submissions and decides which stories will go to conference.
In conference, the submissions must be read by a panel of 3 editors. Since Submission Manager assumes that only one person has access to a submission at one time, LitMagA creates a dummy contact with the email address conference@litmaga.com. All conference editors have access to this email address. The genre editor forwards all final choices to conference@litmaga.com, and the editors log in to this account separately to read the final choices and make their decisions.
How LitMagA groups its readers:
| editor: | Managing Editor
The managing editor needs to have access to all submissions in order to assign the stories. |
| access group 1: | Slush readers
These readers will have access only to forward 2 (recommend reject) and forward 4 (recommend accept). |
| access group 2: | Second readers
These readers will have access to forward 3 (confirm reject) and forward 4 (recommend accept). |
| access group 3: | Genre Editor
The Genre Editors will have access to all forwards, and all rejects, but not to Accept. Accepting will be done by the Managing Editor who has editor level access to the system. |