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:
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 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 file, which is stored on the publication’s server. The submission file can be any file type. By default Submission Manager accepts the following file types: DOC, DOCX, PDF, RTF, TXT. You can customize the file types and sizes that Submission Manager accepts.
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 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)|
|blocked:||Contacts who have been blocked entirely from using the system (for example: submitters who have abused the system)|
For staff members, access level is determined by the admins in the contacts area. When a submitter creates an account, his/her access level will always be NULL.
Submission Manager is designed to be accessed by a web browser. It has been tested on a wide variety of current browsers including Chrome, Firefox, Safari, Internet Explorer, and Edge. 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.
A brief note about file permissions: Submission Manager is written in PHP and needs to be able to read and write files and folders to your web server. In a UNIX environment it is necessary that the PHP user has full read/write access to the parts of your server’s file system where Submission Manager stores its files. This can usually be accomplished by configuring PHP to run as the same UNIX user as the one that owns your files/folders.
To install Submission Manager on your server unzip and upload all files to the directory you created prior to installation (for example: https://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: https://www.example.com/submissions) into your web browser’s address bar and hit return. You will be led 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.|
|redirect_url:||Submitters will be sent to this URL following a successful submission. If you are accepting payments for submissions, this URL should point to your payment gateway. Redirect URLs can be set globally here, or by genre in the genre configuration. If left blank, the default submission confirmation will be displayed.|
|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. (https://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.|
|font_size:||Base font size. Other fonts will be larger/smaller relative to the base.|
|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.|
|border_radius:||Rounding of borders (in pixels).|
|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. Submission limits can also set by genre in the genre configuration.|
|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.|
|default_sort_order:||This determines default sorting of submissions. The default is date ascending.|
|* 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.|
|mail_method:||The method by which mail notifications will be sent (options: mail, sendmail, smtp).|
|smtp_auth:||Check this if you SMTP server required authentication.|
|smtp_secure:||Set SMTP security protocol (options: SSL, TLS).|
|smtp_port:||SMTP port number (if using SMTP authentication)|
|smtp_host:||SMTP host name (if using SMTP authentication)|
|smtp_username:||SMTP username (if using SMTP authentication)|
|smtp_password:||SMTP password (if using SMTP authentication)|
|submission_price:||Price charged for submissions. Price can be set globally here, or by genre in the genre configuration.|
|currency_symbol:||The symbol displayed in front of all prices|
|success_result_code:||The result code returned by your payment gateway indicating a successful transaction.|
|payment_redirect_method:||This determines by which method payment variables will be sent to the payment gateway. The default is GET, however some payment gateways require POST or cURL.|
|cc_exp_date_format:||credit card expiration date format|
|captcha_site_key:||Google reCAPTCHA Site key (to prevent robot submissions)|
|captcha_secret_key:||Google reCAPTCHA Secret key (to prevent robot submissions)|
|mysqldump_path:||Path to the mysqldump program to make database backups|
|csp:||Content Security Policy|
|default_country:||default country on main submission form|
|exclude_countries:||comma separated list of excluded country codes (use "USA_only" to exclude all but USA)|
|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.|
|default_mailing_list:||default state of mailing list checkbox|
|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. Many publications use this to manage contests as well as different literary genres.|
|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”.|
|show_date_paid:||When this is checked, the “date paid” column will be visible in all submission displays. Unpaid submissions will display with a red border.|
|show_payment_fields:||show credit card fields on submission forms|
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]', 'port' => '[port]' ); define('INSTALLED', true); ?>
Update the [host], [username], [password], [name], and [port] 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.
Submission Manager stores all of your data (contacts, submissions, actions, configuration, etc.) in your mySQL database. It is critical that you regularly backup your data! MySQL comes with a backup utility called mysqldump. You can run this utility directly from Submission Manager in the Maintenance Area. It is highly recommended that you run this backup utility often to make sure that your data is safe. It is further recommended that you automate this process (using cron on a UNIX server or the Task Scheduler on a Windows server). Check with your server administrator or read your server’s documentation for more information on how to automate this process.
The authors of Submission Manager are not responsible for any data loss.
Submission Manager stores all of your submission data online. It is up to you to protect this data. This is crucial if you are using Submission Manager to collect submission payments.
Two important ways to make your Submission Manager installation for more secure:
Security note for those accepting payments with Submission Manager: If you are using submission manager to process payments, you must be running the entire installation over an SSL/TLS encrypted connection. And any links on your website to your Submission Manager installation must use a secure URL. So if you link to your submission page from your home page, the URL should be https://www.example.com/submissions/ rather than http://www.example.com/submissions/. It is further recommended that you put in place an automatic redirect for all HTTP traffic to HTTPS. This can done using an Apache .htaccess file.
You should now point your browser to the directory where Submission Manager is installed. (for example: https://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: firstname.lastname@example.org). 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.
Submitters can log back in to their account at any time using the email address and password they entered during their initial submission. When submitters 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:
This page also contains a form by which contacts can reset their passwords.
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 admins or editors first log 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.
Searching by keywords: Staff members can search by any word or phrase that appears in the submission ID#, submitter ID#, submitter name, submission title, comments that the submitter left when submitting and notes that staff members left for submissions. Enter one or more keywords in this box. To search for an exact phrase enclose the phrase in double quotes (for example: “Good Morning”). To search for a specific submission ID# then prefix the number with “id:” (for example: id:123).
Filtering by other criteria: Staff members can search by specifc criteria based on genre and by the last action performed on a submission.
|genre:||This field 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.|
|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 whom 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 “last action” field is set to any of the forwards.|
|sort:||This field allows the staff to sort the selected records by date in either ascending or descending order.|
|paid only:||When checked, search results will only include submissions where the “date paid” field is filled in. This check box is only visible when “show_date_paid” is checked in the General Configuration.|
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 keywords:||(leave blank)|
|last action:||forward 1|
|find keywords:||(leave blank)|
|last action:||no 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|
|date paid:||The date that the submission was paid. This column is only visible when “show_date_paid” is checked in the General Configuration.|
|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 writer’s 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 customized 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 submission ID # or the number in the action column. 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.
Accepts, withdrawals, and rejects work in the same way, but for these actions the “to” field will be grayed 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:
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 with 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 (i.e. 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 email@example.com, they will select:
|show me:||any contact|
|show me:||any non-staff|
|show me:||any staff|
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 mailto 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 6 standard reports. These are designed to give admins and editors an overview of the data on the system. The reports are:
|daily report:||This report shows all submissions and actions that were entered on a given day. By default, the “date” field is pre-populated with the current date. To see a daily report on a different date simply enter the date in the “date” field using the YYYY-MM-DD format and click show report.|
|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.|
|actions by staff:||This report shows a count of all actions entered by each staff member. Counts are broken down by action type. In this report, staff members are sorted first by access level, and then by last name.|
|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 six 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.|
|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.|
File Types: Submission Manager is preconfigured to only accept file types with the following extensions: DOC, DOCX, PDF, RTF, TXT. Submission Manager will only upload files that have a valid file extension. Admins can add/delete/update file types using this configuration page.
Groups: Submission Manager comes preconfigured with 7 staff groups: admin, editor, and active 1-5. This page allows admins to set which groups can forward submissions to which others groups. Admins can also flag certain groups as “blind” which means any member of that group will not be able to see the contact info for submitters.
Genres: Submission Manager comes preconfigured with 3 genres: poetry, fiction, and nonfiction, but you can add as many genres as you like. Genres can have their own price, submission limit, and redirect URL. If you choose to set any of these variables here, your genre settings will override the settings on the General Configuration page. To add new genres, type the genre name in the new field and click update. Genres have the following variables:
|Genre ID:||Unique numeric indentifier for each genre.|
|Name:||The name of the genre.|
|Submission Limit:||The number of times that each submitter can submit using this genre. This limit overides the global limit set in the General Configuration. Set to 0 for no limit.|
|Redirect URL:||Submitters will be sent to this URL following a successful submission. If you are collecting payments for this genre, this URL should point to your payment gateway.|
|Price:||Price for submissions to this genre. This limit overides the global price set in the General Configuration.|
|Active:||When unchecked this genre will no longer be available for submissions.|
|Blind:||When checked submissions in this genre will have hidden submitter contact info so the staff cannot see who is submitting.|
If you turn off genres on the General Configuration page, this area will still appear, but will not affect how the system runs.
Payment Variables: Submission Manager can collect payment data and send it off to your payment gateway following each submission. To do this, you will need to tell Submission Manager which variables your payment gateway requires that you send to it, and which variables they will return. This configuration area allows you to control this process. We highly recommend that you have an experience programmer manage this part of the installation. When you first install Submission Manager, no payment variables will be set.
Outgoing Payment Variables: These are the variables that are sent to your payment gateway. Consult your payment gateway documentation to determine which variables are required to process payments. Some will be constant (like the login of your payment account) and some will taken from the submitter data (like the submitter’s name and credit card information). In the name field, type the Name of the variable required by your payment gateway. In the value field, type the data Submission Manager should send. If the information is static, simply type the information in. For example, if your login for the payment gateway is “Example”, Simply type “Example” in the value field. If the information needs to come from submitter data, you may use the local variables shown at left. For example, If you need to send the price, type $price in the value field. Variables that come from submitter data should be preceded by the dollar sign ($).
Incoming Payment Variables: These are the variables your payment gateway returns. Submission Manager requires two return variables.
Submission Manager does not store the result code for each record, it uses the result code to update the date paid field in the submission record.
The maintenance page stores processes for managing the data on the system. Currently it has seven 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 retains 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.
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: firstname.lastname@example.org).
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.
This function will backup your Submission Manager mySQL database using mysqldump. The server path to mysqldump can be set in General Configuration using the mysqldump_path setting. By default this is set to simply mysqldump which assumes that the program is in your server’s PATH configuration. You may have to set an explicit path, such as /usr/local/mysql/bin/mysqldump for example.
This function will purge submissions and their related actions and files. You can choose a range of submissions based on dates.
WARNING: This will permanently delete data from your database! Please backup and archive your database before using.
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.
This will show the versions of your installed Submission Manager, the latest version of Submission Manager, PHP, and mySQL.
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.
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 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 reader recommends no, it goes on to a second reader for a second read.
If the second reader 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:
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 email@example.com. All conference editors have access to this email address. The genre editor forwards all final choices to firstname.lastname@example.org, and the editors log in to this account separately to read the final choices and make their decisions.
How LitMagA groups its readers:
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.
Submission Manager can be used to collect payments for submissions. This can be done globally, or for a specific genre. Before collecting payments, you must first set up an account with a payment gateway, such as Paypal. Your payment configuration will be determined by the requirements of your payment gateway. Submission Manager will send payment information to this gateway, and will receive payment confirmation from this gateway. Your payment gateway will require a return URL. This URL will be the absolute URL of submission manager installation followed by /payment.php. For example: If your submission manager is installed in https://www.example.com/submisssions/, the return URL will be https://www.example.com/submissions/payment.php. In addition to the information above, the areas of the documentation that specifically refer to working with payments and a payment gateway are as follows:
Be sure to read them carefully, that your site is secure, and that you have tested payments thoroughly before going live.
Below is an example of baisc paymet variables for PayPal’s Payflow Link Service:
|LOGIN||[your PayPal login name]|
|PARTNER||[your PayPal partner name]|