This feature allows (by option) an organization to allow its members to see
tickets from other members. It can be used beside or instead of the
automated collaboration feature. Now, collaborators retain access to tickets
on which they participate; however, sharing can be used to enable access to
other tickets owned by their organization.

If the subject field is something crazy, such as an HTML field, ensure that
the layout of the ticket queue is preserved and properly truncated.
Furthermore, ensure that the HTML is properly rendered on the client and
staff ticket view pages.

This patch makes the open and closed ticket counts on the client portal
relative to the help topic search. It also hides the counts when doing text
searches so that an extra count query isn't necessary.

This patch adds to the client interface the ability to filter tickets on the
client portal by help topic, as well as a "clear" feature to clear search,
sort, and filter options.

Use http::build_query instead of inline urlencode

Use generic attachment table for all attachments system-wide.
Drop thread entry attachment table

The commit also renames some fields in department table.

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.

This helps in long UTF-8 characters as the bytes were previously counted and
the width of the characters was assumed to correlate with the count of the
bytes in the text. This method allows the browser to calmly truncate the
text according to the available space in the page where the text is
rendered.

Use the cdata field when searching and sorting the ticket listing on the
client side.

This is necessary to avoid confusion vs. closed state.

Ticket numbers are now configurable as a system-default and by help topic.
Previously, an administrator could select between six-digit random and
sequential numbers. Now, the sequence is selectable so multiple sequences
as needed, and a format can be specified to define how the ticket numbers
look. Formats can also be defined for each help topic.

The software defines at least three contexts for the phrase "Open"

  * The name of a ticket queue (Open tickets)
  * A status of a ticket (Open / Closed)
  * An action to be performed (Open a ticket)

References:
(Crowdin login required)
http://i18n.osticket.com/translate/osticket-official/148/enus-de#2915

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

In both the client and staff interfaces, where the URL and request
parameters were echo'd back without any escaping

Client accounts now that the user is verified either via staff or the
client's email mailbox, there's a much lower risk to showing a verified user
other tickets and virtually no reason that an administrator should have to
turn the feature on.

Drop join to the user table
Use internal ticket id instead of ticket number

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.

Add tickets count to ticket's status filter dropdown.

Use non-minimized css - users can minimize on their own

Replace the ticket_{message,response,note} tables with a single
ticket_thread table that will contain data for all three current message
types. This simplifies much of the ticket thread code and paves the way for
other types of messages in the future.