If something fishy, like an Array is received into the password reset system
or any part of the Staff management system, it should be rejected.

References:
http://osticket.com/forum/discussion/76003/sql-attack

The change will allows staff to open a new ticket without going through the
"forced" user lookup popup. On cancel the staff is presented with a
simplified user info form with email and name being the only fields
required.

Required for PHP 5.5 compatibility

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.

Missed one.. :-(

Couldn't find the rebase to this.. actually, I didn't look, I'm still struggling with git and eclipse, would probably have been easier with vim! Anyway, rewrote changes for 1.7.

If a user is created / selected before opening a ticket (very likely the
case in the SCP), the email address and name should be unpacked into the
$vars dictionary prior to creating and processing ticket filters

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.

This is instead of optimizing the lock table for every cron run, which
wastes a lot of db server io

And deadband session token updates to 1 per 30 seconds

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

THISPAGE is unreliable for CLI cron calls. It was historically used so the
admin could figure out which file/page generated the error. But with
backtrace support we no longer need it.

Arrange templates in a group by their respective use in the system:

  * System Management Templates
  * Staff Ticket Templates (Alerts and Notices)
  * End-User Ticket Templates (Autoresponder)

This provides an interface to sort the templates and make them easier to
find and provides a nice place for new templates to be added without making
it increasingly more difficult to locate templates in the list.

This patch also fixes the missing templates in the drop-down list when
editing an implemented template.

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

This patch addresses an issue where a client may have upper-case letters in
their email address. When visiting the client portal to check the ticket
status, previously, the exact same case would be required in the 'Email
Address' box.

This patch remove the case sensitivity for email logins.

Extra forms associated with the help topic are now shown above the ticket
details form on both the staff and client interfaces.

Fixes #390

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.

This is especially important if the html ticket thread is disabled. In such
a case the message body will still be HTML, but an HTML email should not be
sent out.

Fixes #374

(And newer versions don't seem to like the legacy code). This patch uses a
`Refresh` header for IIS versions prior to 7.0 (included with Windows Vista
/ Server 2008). Starting with IIS 7.0, the Location header should be
properly handled by IIS.

Fix adding fields to an existing form

Use a union query to avoid using DISTINCT and lots and lots of joins in the
from clause.

Initial tests seem to indicate about a 80% faster (~500ms down from ~800ms)
on querying about 9k tickets).

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.