This commit addresses an issue where the validation error for trying to save a Ticket without a Help Topic was not being shown as a result of the error message that was added to ensure that the Help Topic selected is Active.

This commit adds an Admin setting that requires a Ticket to have a Help Topic before it can be closed. It can be set by going to:

Admin Panel | Settings | Tickets | Require Help Topic to Close

If enabled, Tickets will have a warning banner across the bottom of the page, a warning banner when trying to change the Ticket status to Closed, and a warning flag beside the field when editing the Ticket.

By default, this setting is NOT enabled.

- On ticket edit, only display inactive help topic warning if the ticket has a help topic
- Inline edit file save fix
- Remove future search/filter criteria for datetime fields that can't be in the future
- Fix calculations for 'next 7 days' and 'next 30 days'. They were selecting dates between now and n days AGO instead of between now and n days in the future

- On ticket edit, only display inactive help topic warning if the ticket has a help topic

This addresses issue 4028 where upon editing a ticket the Internal Note’s
Instructions states that it is required in order to save the changes to
the ticket. In reality this is not the case; the Internal Note is
optional. So this updates the Instructions and changes the word 'required'
to 'optional'.

Use class instead of id on form element that triggers overlay on submit.

Unify ticket source and preserve original (e.g Wed) source on ticket edit.

Also fix several javascript errors on ticket edit

Allow for permissions to be registered dynamically. This will
allow for the ability for models and plugins to register permissions.

This patch adds support for automatic date and time formatting based on a
selection of locale. The locale can default to the system or user specified
language+locale, or can be elected separately. For instance, English
speakers can pick between US, GB, and many other English speaking locales.

This also removes the need of the %timezone table and uses the timezonedb
built into PHP 5.3+. User's can now select from a much longer list of
database and no longer need to deal with the DST checkbox.

Also fix a crash when re-rendering the new ticket by staff page after a
validation error.

Multilanguage Support via gettext

- added gettext encapsulations to all texts i thought necessary
- added fallback function for the case that the gettext extension isn't loaded
- added browser language detection
- added gettext to the list of optional extensions in setup
- rewritten some of the texts to use sprintf instead of appending strings
- added german translation file
- removed mark_overdue-confirm from cannedresponses.inc.php

extend multi language support and a fex fixes

- Better detection of translation files
- Added functionality to redirect language codes (see redirecting
language codes)
- Ticket Status can be translated
- The Datepicker can be translated
- Extended functionality of 'testlang.php' to show what language code is
used to translate

Forgotten to apply a patch from RC5 to RC6

- Forgotten to change $var to $vars in line 380 of class.mailfetch.php
- Removed unneeded comment

Added php_gettext as primary translation engine

- Added php_gettext support (thanks to Danilo Segan and Steven
Armstrong)
- php_gettext is now the primary translation engine
- Extended language detection functionality

Add error/misconfiguration checks and fix undefined variables

We're sticking with user for now until 2.0

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

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

Fixes osTicket/osTicket-1.8#296

Previously, the user information could only be modified on the ticket-view
page. For instance, if creating a new ticket for a user, no new information
could be added or modified on the user until after the ticket was created

Fixes osTicket/osTicket-1.8#281

Allows the client to be changed on a ticket. Previously, only the
information about the client associated with the ticket was editable. This
patch permits assigning a completely different user to the ticket.

PHP can't discern the difference between d/m/Y and m/d/Y when just the date
is submitted to strtotime(). Unfortunately, strptime() is not available
until PHP 5.1.0. This patch forces datepickers to change their values to
YYYY-MM-DD upon submission to disambiguate parsing issues.

Fixes #832

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.

Previously, form sections were grouped into form sets for reusability. This
patch drops the form sets and makes form sections the new "forms".
Eventually a section-header field will be added that technically does not
add any dynamic data to the form, but allows for the same feature as having
a form set with multiple sections.

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

Process inline attachments in thread entry and support inline images in
piped emails

Support inline images across the system, with draft support

Migrate to a single attachment table
    That way we don't need a new table for everything we need to attach an
    inline image to (like a signature, for instance)

Add richtext support for internal notes

Implement images on site pages

* Image paste in Redactor
* Make non-local images optional
* Placeholder for non-local images
* Fix local image download hover
* Don't re-attach inline images

Make sure SLA plan is 'active' when marking tickets overdue.