necessary to avoid adding internal virtual address as a collaborator.

Store delivered-to email ID - giving us the ability to reply FROM specific
email address as opposed to the department's email.

This is required when validating a message which could be a string or an
object.

Rename routines to make it a little clear on what they do

Exclude the auto-responding email from possible alerts sent to staff

The concern here is possible loop when an alert to staff bounces back to the
system.

Disable auto-response on a bounce.

A ticket owner can't be a collaborator.

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

The concept of extid is being retired to pave-way for customizatable ticket
numbers.

Make sure new message notice goes to the user who posted the message not
neccessarily the ticket owner.

Add routine to get ticket's recipients (owner + active collaborators)

Add EndUser lookup by email to TicketUser - returns a decorated user

Provide facility to set collaborator status on add.

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.

Fixes a regression in 1.8 where user names and emails submitted via the web
interface would not properly be detected by the filter system for rejection.

References:
http://osticket.com/forum/discussion/75456/v1-8-ticket-filter-for-banning-domain-doesn-t-work

Previously, due to a bug in Ticket::getPhone(), the first digit of the
formatted phone number was displayed only. This patch will allow display of
the entire formatted phone number.

Fixes osTicket/osTicket-1.8#248

'where 1' and 'where 1=1' gives me hives...

If a ticket is currently unassigned and your respond to it, it's yours. If a
ticket is closed and later reopened due to a new message, the last
respondent will always be assigned if available at the time.