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

Which will help fight off spammers. This should be coupled with logic that
will add some enticing fields, like 'email' and 'name' to invite bot input.
Then, on the form processing side, a spam submission can be detected and
handled differently from human submissions. This should lessen reliance on
CAPTCHA only as spam detection.

Allow for type and encoding specification of the message body and better
describe the integration with custom form fields.

Including adding support to the TCL uninitialized variable reader to ignore
class-static variable access as well as detect inline functions and their
closure arguments.

Fixup several minor bugs concerning initial experience

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.