Moved to an initial form which specifies the ticket's priority and issue and
changed the rendering to render things properly. Now the user can decide
where priority shows on the client side, and the priority privacy setting is
placed in the dynamic form wizard.

The standard form is added to every ticket without option. Extra forms can
be defined and associated with help topics which can additionally be added
to tickets upon creation. This allows for standardization of the dynamic
data location for searches and filtering.

Implemented advanced search for dynamic data. Along with reinstating the
basic ticket search on keywords

Implemented ticket filtering on dynamic data for both keyword searches as
well as searches for special fields (drop-down lists, etc.)

Phone number for users is now completely optional

This moves client information like name and email address out of the general
dynamic forms data for a ticket. It really paves the way for the first-class
user of the future.

Previously, form sections were grouped into form sets for reusability. This
patch drops the form sets and makes form sections the new "forms".
Eventually a section-header field will be added that technically does not
add any dynamic data to the form, but allows for the same feature as having
a form set with multiple sections.

Use an internal hash table of join information to prevent multiple joins
over the same path. Also use table aliases in order to support self joins or
otherwise multiple joins to the same table using different paths.

*This is a major redesign / rework of the osTicket base*

This patch drops the concept of static ticket metadata and allows for an
admin-configurable arbitrary data that is attachable to tickets

The system is architected such that the base osTicket install now comes with
a "default" form that has fields for subject, name, email, and phone number.
This form is editable to allow for the addition of arbitrary other fields;
however, the basic fields must remain in order to be associated with a
help-topic and attached to a ticket.

This concept can be expanded to allow for arbitrary data associated with
registered clients or ticket thread items.

Forms are comprised of sections. Sections have a title and instructions
properties and a list of fields. Fields have various implementations to
represent different data such as text, long answer, phone number, datetime,
yes/no, and selections, and are configurable to define the look and feel and
interpretation of the respective form field.

Dropdown lists are represented as "Dynamic Lists", which are
admin-configurable lists of items. Dropdowns can be optionally represented
as Bootstrap typeahead fields.

This also adds the start of a simple ORM which will hopefully be expanded in
the future to support multiple database platforms. Currently, only MySQL is
implemented.

HTML ticket thread, inline images and draft support

Reviewed-By: Peter Rotich <peter@osticket.com>

This patch changes the behavior of the mailer to support a 'text' option to
hint if the message is a text-only message. If so, no HTML processing will
be performed on the message and a text-only email (with no inline
attachments) will be emitted and sent.

Ticket notice and ticket auto-reply should not be formatted inside a table
since the %{message} or %{response} should be allowed to flow freely in the
email rather than be crammed inside the table.

Process inline attachments in thread entry and support inline images in
piped emails

Support inline images across the system, with draft support

Migrate to a single attachment table
    That way we don't need a new table for everything we need to attach an
    inline image to (like a signature, for instance)

Add richtext support for internal notes

Implement images on site pages

* Image paste in Redactor
* Make non-local images optional
* Placeholder for non-local images
* Fix local image download hover
* Don't re-attach inline images

Include changes from 1.7.2

Conflicts:
	main.inc.php

Change PDF print to show custom logo

Reviewed-By: Peter Rotich <peter@osticket.com>

If the GD extension is not available for the PHP installation, then use a
copy of the default client-site logo with the alpha channel removed.

Crazy performance penalty scanning blob tables

Reviewed-By: Peter Rotich <peter@osticket.com>

Better converting from ticket thread to PDF

Reviewed-By: Peter Rotich <peter@osticket.com>

Die with internal server error on misconfiguration

Reviewed-By: Peter Rotich <peter@osticket.com>

Fix parsing of attachments

Reviewed-By: Peter Rotich <peter@osticket.com>

Use base64 encoding for text version of emails

Reviewed-By: Peter Rotich <peter@osticket.com>

Assume that text in the database is encoded in UTF-8 and assume that it is
HTML text and the entities should be decoded prior to display in the PDF.

Fixes #756

When scanning the file_chunk table for orphaned file chunks that can be
deleted, apparently, MySQL will read (at least part of) the blob data from
the disk. For databases with lots of large attachments, this can take
considerable time. Considering that it is triggered from the autocron and
will run everytime the cron is run, the database will spend considerable
time scanning for rows to be cleaned.

This patch changes the orphan cleanup into two phases. The first will search
just for the pk's of file chunks to be deleted. If any are found, then the
chunks are deleted by the file_id and chunk_id, which is the primary key of
the table.

The SELECT query seems to run at least 20 times faster than the delete
statement, and DELETEing against the primary key of the blob table should
be the fastest possible operation. Somehow, both queries required a full
table scan; however, because the SELECT statement is explictly only
interested in two fields, it is more clear to the query optimizer that the
blob data should not be scanned.

References:
http://stackoverflow.com/q/9511476

Or internal server (database) outage

Some mail clients and mail brokers do not properly handle quoted-printable
encoding, used in osTicket outgoing emails. Oddly, the end mail clients
render the email with trailing equal signs (=) at the end of every line,
where it was added due to QP encoding.

References:
http://www.osticket.com/forums/forum/osticket-1-7-latest-release/troubleshooting-and-problems-aa/10708-solved-microsoft-exchange-internet-mail-lines-end-with
RFC 2045 section 6.7, http://www.ietf.org/rfc/rfc2045.txt

If the body is declared with inline disposition and no filename, the parser
engine would create an incorrect attachments list.

Record message-id's for rejected emails

Reviewed-By: Peter Rotich <peter@osticket.com>

Limit admin alerts to logged messages.

Reviewed-By: Jared Hancock <jared@osticket.com>

Forbid empty reply separators

Reviewed-By: Peter Rotich <peter@osticket.com>

Expose fail count to shell environment

Reviewed-By: Peter Rotich <peter@osticket.com>

Also, run the tests in the packager. The packager will automatically run the
regression test suite prior to packaging a release. The package will not
build if there is at least one fail from the regression tests.

Allow deployment of setup/

Reviewed-By: Peter Rotich <peter@osticket.com>

Useful for initial installs, where deployment of the `setup/` folder is
required for the initial install. Thereafter, deployment can be run without
the setup option so that the rest of the codebase can be maintained (already
supported)

Disambiguate version string when running off of git

Reviewed-By: Peter Rotich <peter@osticket.com>

Message id tracking revisited

Reviewed-By: Jared Hancock <jared@osticket.com>