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.

This mostly helps when fields change types. If the type of the field
currently cannot convert previous data to a string (like if a short-answer
field was changed to choices), the textual representation of the PHP value
of the field data is given.

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.

They are only available for tickets arriving via the email channel. All
other channel (including email) use the new ticket form to record the
subject and body, which are mapped to the 'Issue Summary' and 'Issue
Details' fields respectively

Structure the drop-down list for the `what` column to be future-minded
concerning custom user data matching.

If a custom list item were added to an email template, and there is no data
for the field (ie. the field is not required) when the template is rendered,
the system would crash.

toString() is required to return a string, no matter what. This patch
cascades the (string) coercion to the current value of the list field if it
is not an instance of a DynamicListItem

If the text does not match the value on record in the custom list, then the
value entered in the field cannot be accepted.

NOTE: This may have unintended i18n consequences, where there are varying
ways to write a letter in Unicode which may be rendered the same but will
not be correct with a string ==.

If a dynamic list is displayed as a typeahead box, the value, when saved,
will be confused with the corresponding ID field for the list. MySQL
supports numeric comparison between the INT id column and the textual value
column. Therefore, if a typeahead field has the value of '01 - GooGoo', then
record will match the ListItem<id=1>, regardless of which list the item is
defined for.

This patch resolves the issue by submitting the ID number of the list
selection in the HTTP form.

If the entry answer being updated does not affect the ticket details form
(with type=T), then the updates do not need to be applied to the
ticket__cdata table.

If a field on the ticket details form changes type, recreate the cdata table

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.

For use in the materialized view column names

Fix dropping of materialized view when variable name is changed

Ensure view exists before merging updates

Prevent possible sql injection error in field name used in the materialized
view.

Prevent possible xss error in the display of the field label and variable
name in the admin panel.

Fixes #374

Fix adding fields to an existing form

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.

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

Fixes osTicket/osTicket-1.8#296

The check in DynamicFormEntry::getAnswers() will use the cached _values
array if it is not set to null. Previously, the ::save() method would set it
to an empty array.

Again, fix issue where multiple mails fetched in the same fetch run will set
the user of each of the mails to the user of the first email fetched.

The previous patch neglected to pass the new $cache argument through the
inherited UserForm::getFields() function.

If two emails were fetched in the same timeframe, they may both be assigned
to the same user account.

Add update routine
Add updated date getter

without required, internal contact field

Fixes osTicket/osTicket-1.8#203

  * Require a label on form fields
  * Require variable name to be unique per form
  * Fixup duplicate phone numbers on upgrade

Fixes a case where multiple tickets are created in one request (such as a
cron job triggering multiple email fetches). The TicketForm::getInstance()
called in Ticket::create() used a singleton pattern to retrieve a cached
instance of the TicketForm. In the case of ticket creation, each ticket
needs a new TicketForm entry instance.

Fixes #111

The typeahead for user email address was dropped somewhere along the way

Fixes #77

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

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