Additional info supplied by user Missing Info Parsing

[benne238]

What Happened

Webmaster 137 broke in the live queue

Expected Behavior

Webmaster 137 shouldn't break

Steps to Reproduce

1. Open webmaster queue in the live wq2

Logs

Issue fix: implement an error parse that accounts for missing info in the additional info supplied by user section

[benne238]

The Culprit

Additional information supplied by user needs basic header info. This does not have basic info

=== Additional information supplied by user ===


FYI—they were okay at the beginning of the semester.  This is a new problem as of this week/recently.


===============================================

[benne238]

webmaster Queue Fix

The issue stemmed from a lack of error handling for empty header information from additional info supplied from user sections. That has now been fixed with #140

Additional info supplied by user structure:

=== Additional information supplied by user ===

Subject:  Subject Line Here
From:  "From_Name" <email@aol.com>
Cc:  "epicsite@ecn.purdue.edu" <epicsite@ecn.purdue.edu>,
            "CC Name One" <ccone@purdue.edu>,
            "CC Name Two" <cctwo@purdue.edu>,
            "CC Name Three" <ccthree@aol.com>
Date:  Mon, 19 Jan 2015 11:30:44 -0500

content...


===============================================

The structure consists of a beginning delimiter, a newline indicating header information, header information, a new line indicating the end of the header information and the beginning of the content, two new lines and the ending delimiter. However, the below queue resulted in an error during the date sort within the api:

=== Additional information supplied by user ===


content


===============================================

The problem with the section above (taken from webmaster 137 in the live queue) was with the handling of the header information. The api does not expect a fixed number of lines within the header, meaning that 0 lines of header information can be included within the reply-from-user section and still result in a successful parse for the rest of the section. However, a line indicating the date of the section must be provided in the header so that the script can sort the section by date, something that was not checked.
In order to successfully parse correctly, the api now looks for a date in the header info and returns a parse_error if none is found.

[campb303]

Waiting for #140 to be merged.