If a client is already logged into the client portal and attempts to submit
a new ticket, the ticket will be rejected if the contact-information form
has a required field other than `name` and `email`.

This patch fixes `class Client` so that the user-id is fetched from the
database and made available via the `::getUserId()` method. This was already
corrected in the `develop-next` branch for v1.8.1. The `uid` field is passed
into `Ticket::create()` so the user form validation is bypassed.

This commit should be ignored when merged into the 1.8.1 codebase.

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

Fix display of priority field in queue export

Reviewed-By: Peter Rotich <peter@osticket.com>

Also removes the fetching of priorities separately and addresses sorting of
priorities by the ID field rather than the urgency field.

Fixup querying drop-down lists via advanced search

Reviewed-By: Peter Rotich <peter@osticket.com>

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.

forms: Fix ambiguous id / value for typeahead

Reviewed-By: Peter Rotich <peter@osticket.com>

Log password reset attempts

Reviewed-By: Peter Rotich <peter@osticket.com>

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

Conflicts:
	include/mysqli.php

Allow staff to cancel user lookup popup when creating a new ticket

Reviewed-By: Jared Hancock <jared@osticket.com>

Make using `realpath` safer

Reviewed-By: Peter Rotich <peter@osticket.com>

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.

Revisit template management page

Reviewed-By: Peter Rotich <peter@osticket.com>

forms: Allow decl of prompt and default for choices

Reviewed-By: Peter Rotich <peter@osticket.com>

Fix parameter count to TicketLock::lookup

Reviewed-By: Peter Rotich <peter@osticket.com>

Required for PHP 5.5 compatibility

Ensure a ROOT_PATH is defined for CLI apps

Reviewed-By: Peter Rotich <peter@osticket.com>

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.

filters: Unpack the user information before filter

Reviewed-By: Peter Rotich <peter@osticket.com>

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

Several database performance tweaks

Reviewed-By: Peter Rotich <peter@osticket.com>

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

Drop the data table on field type change

Reviewed-By: Peter Rotich <peter@osticket.com>

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