The ThreadEntryWidget has a potential cross site scripting (XSS)
vulnerability if data was posted directly to the page hosting the widget

Vulnerable URLs:
view.php, open.php, scp/open.php, scp/tickets.php

The content received in the HTTP POST is now correctly escaped when it is
echoed back to the user agent.

The `id` needs to be changed for the new clone in order for the POST data to
line up with with new field

Sanitize textarea content on export

This make writing new backends (such as LDAP) easier and less copy+pasting
is required.

Otherwise, it might be possible for a forwarded email to accidentally
contain a ticket link, with which a sinister individual might be able to use
to register for account on behalf of the original client, and, at the same
time, be able to change the user's email address to his/her own.

Priority field and custom list fields have a prompt value (shows up only for
drop-down widget). And the short and long answer fields have a placeholder
configuration item.

Allow the administrator to enter a prompt to be shown in the choices
drop-down for choice fields. Also add the option of selecting a default
value from the list initially rather than displaying a prompt.

This is necessary because the system depends ticket priority to sort and
display ticket data.

Also add in the user email address after the user name.

This patch also adds an ::export() method to the FormField() class which
allows a field to define how the data should be formatted when exported.

Fixes #390

This patch introduces an automatic materialized view to speed database
performance when querying and displaying the ticket views. This can
eventually be extended to the search and advanced search features to speed
them as well.

The data from the dynamic form entries related to ticket details is copied
to a %ticket__cdata table. The %ticket__cdata table is then joined directly
to the other tables in the query for the ticket view. MySQL is magically
and dramatically faster using this method.

The downside is that the disk usage for the custom data is doubled, and the
time needed to update the dynamic data is at least doubled as the form
entries and the materialized view must both be updated.

This method should also extend well to other database platforms in the
future. It will be likely that most other database query optimizers will
have difficulty joining, scanning, and sorting the table models we have for
custom data fields.

Fixes #356

If the form is constructed as a hash array of fields, allow the getField()
method to return the field based on the key of the fields hash array

Displaying field values on various pages and dialogs could result in cross
site scripting exploits.

Fixes osTicket/osTicket-1.8#296

This includes the initial concept of pluggable authentication along with the
initial concept for a plugin management system.

Unpack user data for filtering purposes for staff created tickets

without required, internal contact field

Fixes #191

When localized date formatting was implemented, saving of those dates in the
database was broken. This fix correctly handles custom date fields to/from
the database.

Fixes #23

Fixes #77

If a form field is required, then a name will be necessary in order to plumb
up the API.

Fixes #64

Fixes #78

Previously, clients would not be able to create tickets if an internal,
required field existed on any of the forms presented to the user. Instead,
they would be stuck at permanent validation failure because there was no
data for a required field not shown.

This patch adds a feature to the form and dynamicFormEntry objects'
isValid() method to receive a callable to filter which fields' errors should
be added to the form's errors list. This allows for more complex validation
where in some cases, validation errors should not be considered on some
fields.

Fixes #45