Background: osTicket allows access to assigned open tickets (both personal
and team assignments) regardless of the assigned department or group. This
is necessary to allow staff to work on tickets in an otherwise restricted
department.

When a staff member closes a ticket, they're credited (ticket.staff_id is
set to staff's id) for the purpose of showing who closed the ticket.
osTicket mistakenly allowed continued access to closed tickets even when the
staff doesn't have access to the ticket based on departmental access.

Show ticket prview when a ticket number is clicked as opposed to ticket
view.
Add collaborator preview tab on ticket preview tool tip.

It turns out that the _id field was not added to the cdata table when it was
created for SelectionField items, because the ::hasIdValue() method was not
implemented. This patch correctly searches SelectionFields via advanced
search.

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.

Provide facility to set collaborator status on add.

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.

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).

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

Fixes osTicket/osTicket-1.8#296

Previously, advanced search was bugged in such a way that the advanced
search on a field without a `name` value would result in a hit of all the
tickets.

Fixes osTicket/osTicket-1.8#288

Change fromForm routine takes the actual form and do validation and call
fromVars with clean data

Add fromVars to do the actual user creation (previously named fromForm.

Use a PHP setup which uses the built-in PHP tokenizer to parse and traverse
PHP scripts to determine (possible) access to uninitialized variables

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.

*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.