Don't show fields disabled by help topic
Pass create mode for pre-selected help topic forms

This commit addresses inconsistencies on how field edit rights and
visibility are are handled.

This addresses an issue where inserting images on a Page or FAQ and having
the setting enabled for "Login required to view attachments." does not
display the images at all when the Page/FAQ renders in view. This is due to
the Page/FAQ update functions that were not updated to fit the new
`id=>name` format for `keepOnlyFileIds()` introduced with `f179cf15`.

This addresses an issue where the create_date variable is showing as Unix
timestamp instead of formatted date. This was due to a typo introduced in
commit `8623ed60` where the `$format` argument was forgotten for
`Format::datetime()` in the `FormattedLocalDate::getVar()` method.

This addresses an issue where configuring a System Email to have a
Department and then editing/saving changes on the configured Department will
change the System Email's Department back to the the default Department.
This was due to a un-needed Department Status check introduced with commit
`1d361b51`. This also updates all instances of Dept Status comparison to be
case insensitive and non-translated.

This adds a setting in the Ticket Settings to give the option of showing the
ticket counts on Top-Level queues. If enabled, this will populate the ticket
counts next to the Top-Level queue names like they used to be. The only
caveat is the counts are triggered by mousing-over any of the queue names as
we only load the counts when we need to display the sub-queues (for better
performance).

This also adds a new format function called `number` (Phase 1). As of now it
will format any integer to a comma separated number (eg. `1337 -> 1,337`).

This commit addresses an issue where we lost the logic for needed GROUP BYs in the dashboard report. They were added back for the Statistics query but not for the query that calculates Response and Service time. This now adds it back.

This commit addresses where wrong "primary" field was used to indicate
Ticket Status column. It also fixes an issue where sorting was done via `id`
instead of `name`.

This commits adds a flag to skip validation on $field->getClean() routine.
This is necessary to allow FileUploadField to fetch "injected" files.

This addresses an issue where poor little `sort_id` was sadly forgotten for
the two main-level queues "Open" and "My Tickets".

This addresses an issue where replying to a ticket causes a Fatal Error for
the system. This is due to the `$ticket` object not being set before the
else statement therefore causing the `getId()` function to fail. This breaks
down the if/else statement to make sure the `$ticket` object is in-fact set
before continuing.

This commit fixes an issue where we were not able to see all of the departments, topics, and agents that should have been included in the report. The logic for the  GROUP BY in the queries was changed, so we just manually added them back in.

This commits adds fallback for queue counts and improves caching mechanism.

This addresses an issue reported on the forum where deleting a User will
throw a fatal error. This was caused by 4558 where the `state` column was
mistakenly overwritten with `event_id`. In addition, this changes `$deleted`
to `$status_id` for better readability.

This addresses an issue where export does not work due to a fatal error
"Unknown column 'R0.state' in 'where clause'". This was caused by 4558 due
to the removal of enums and the `state` column. This updates the filter to
match the `event_id` instead of `state`.

This patch fixes the issue where the configuration was not properly
reloaded during an upgrade. The configuration items were stashed in the
Config class and were not re-fetched from the ::load() method.
Additionally, this patch forces the ORM cached objects to be flushed on
each loop through the automated upgrader to ensure that cached data
which might have been modified directly in the database during the
database process is destroyed.

Clear cached queue counts on queue update and via auto-cron

This commit reverses relevance limit added by commit a9c283ec. This is
necessary because searching for Organization or User name will have low
relevance due to limited size of indexed "document".

Drop checking FLAG_PUBLIC when determining if a queue is private

This commits adds ability to add extra joins to a queryset. If the join has
constraints then it's LEFT joined otherwise straight JOIN is assumed.

This is necessary to fix queue counts for queues with keyword search.

This is pretty weak as implemented, but one of the problems with
searching speed is that, for each page render, the count of the hits is
required. But now the hits query does not actually collect the count for
the search queue. What's worse, the code collects counts for all saved
queues (not including the advanced search), so the counts are not
included. Then, the code re-collects the counts for all the queues since
the advanced search queue count isn't available. Then, since there still
is no count for the advanced search, it will show "0" results after
waiting to count all the other queues.

This cowardly fixes the issue by assuming there are 500 hits, which
allows a few pages. In reality, the pagination system should be rewired
so that it can dynamically add pages until it comes up with a short
read of results, in which case it can assume that it has reached the
end.

This patch adds a few changes. First, the full-text search query is
refactored so that MySQL can focus first on finding matching records in
its full-text search index (in the %_search table) in a subquery. Then
it can focus on matching records against tickets in an outer query
(whether ticket data, thread entries, user info, or organization inf was
matched).  This dramatically speeds up the query for large datasets by
about 20x (about three seconds instead of sixty-something).

Secondly, results are now sorted based on relevance, so the best hits
sort a the top of the list. This is accomplished by adding the
`relevance` to the query sort list via the extra() method. Then, since
no GROUP BY clause is really necessary, it is not added to the query,
which will allow the results not to be re-sorted by the ticket_id. (That
is, the remain sorted by the search relevance).

Third, the relevance has a lower limit of 0.3. Good hits seem to have a
much larger value (like hundreds), so setting a small value will help to
remove hits with barely any relevance to the search terms.

When using a nested query to perform the search for the ticket queue, drop the extra
full-text search criteria join from the outer query. This seems to drop the
`rows_examined` by a factor of two and drops the query time by an order of
magnitude.

This significantly speeds up the re-indexing speed for large databases. Since it is
only important to have the system reindexed--and not necessarily what order the
re-indexing happends, the sorting is really just a waste of resources and time.

This dramatically increases the performance of searching for indexable threads, for
instance, from 260900ms to about 42ms.

This changes the organization of the ticket queue query. It places the criteria of
the queue and the access criteria based on the staff in a query by itself. Then it
joins to that query and selects the columns and annotations in the outer query.

This seems to help MySQL focus on the query in two stages. The first is to find the
one page of results to be shown on the page, and the second is to find all the
information to be shown for each ticket.

If there are annotations in an SQL statement, but there are no aggregate
functions used (such as SUM, COUNT, etc), then a GROUP BY clause is not
technically required. Using one implies sorting of the results to ensure
uniqueness--prior to sorting them according to the requested sort in the ORDER
BY clause.

Prefer agent's queue count instead of rough count when paginating the
tickets. This will make the initial queue load expensive but has an
added advantage of having queue counts available thereafter for drop downs.

This commits also adds entry to auto-cron, to keep queue counts more up to
date in the background.When APCu is not available SESSION is used to cache
the counts.

This adds the advanced option to the queue sort configuration. An index can be
specified to be used for the sorting operation. In some cases, the MySQL query
optimizer cannot select the most efficient index to use when dealing with large
querysets and sorting. This feature, if enabled, allows an administrator to specify
an index which MySQL should use when using the sort.

To use the feature, an `extra` column must be added to the `%queue_sort` table to
receive the index name.

This changes the queue counts shown at the bottom of the page to no longer be
calculated using the SQL_CALC_FOUND_ROWS method of MySQL. Such is very slow for
large recordsets. Instead, a rough count is computed based on the total number of
tickets in the queue without respect for staff access. This is the fastest way to
get a maximum number of possible tickets to be shown. The pagenation interface
should be changed to show only NEXT and PREVIOUS pages where the rough estimate can
be used to provide a rough idea of whether or not another page of data would be
available.

Furthermore, if APCu is available, the rough count is stashed and kept between
requests so that the rough counts do not need to be re-tallied until they would
change from a ticket state change.

Another optimization might be to increment and decrement the queue rough counts when
tickets are created or change states. In such a case, it could be identified which
queues the old ticket would have been (and decrement the count) and which queues the
updated ticket would be in (and increment the count).

If APCu is available, then the queue counts can be cached between requests.
They are automatically cleared and recalculated if the status of a ticket
changes or if a queue or saved search is edited. Otherwise, the queue counts
will expire after an hour and be recalculated anyway.

Somehow on large datasets (like >1M tickets), MySQL can get confused on which
index will provide the best performance. Generally, as systems age, they will
have significantly more closed tickets than open ones. Therefore, it should be
safe to assume that scanning the `status_id` index on the ticket table for
`open` tickets would be the fastest way to arrive at the sort-of short list of
tickets which should need to possibly be aged.

The commit fixes queues display and sorting.

* Require keyword search term to be 3 words or less
* Show keyword search option on Advanced Search dialog

This commit makes Primary Queues buckets for sub queues with forced inheritance of
criteria. Primary queues are now hidden unless there are no sub queues
attached. Agents can still get to primary queue by clicking on it.

The commit also adds default sub queues for Closed queue, utilizing DateTime
periods.