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.

Conflicts:
	file.php
	include/class.file.php
	include/class.thread.php

Export: Make Export Fast Again

File Disposition

This commit ensures that we use the correct disposition for downloading files.

Attachment Names Issue

This commit ensures that we will always get the correct attachment name regardless of if the file content is the same. Additionally, it ensures that the file_ids for attachments are compared in the correct order (elseifs)

This commit ensures that we will always get the correct attachment name regardless of if the file content is the same. Additionally, it ensures that the file_ids for attachments are compared in the correct order (elseifs)

Add period to DateTimeField

Form Attachment Issues

- Make sure we keep attachments in the session even if the page refreshes to display an error message
- Reverse the array of files to be id => name instead of name => id
- Make sure we retain the old ticket or task id if we encounter an error while trying to create a ticket or task from a thread entry
- Make sure we have a valid fileId before returning file info
- Make sure we can still add files for Canned Responses (id and name flip issue)
- Make sure we can still add attachments to Internal Notes for Tickets and Tasks

Add support for periods to DateTimeField allowing the search on range of
dates based on set period like 'Today', 'This Quarter' or 'Last Week' etc.

View All Tickets for User

Ticket Sources

This commit ensures that we will always have the correct display of values for the Ticket Source regardless of if the key and value differ.
Ex: if we had a Ticket Source that contained a space in the value, the key would be camelcased

When clicking 'All Tickets' for a User from within a Ticket, make sure we search using the User's email address instead of their Full Name in case we have users with the same name.

Filter Action Validation Fixes

change old wiki urls to new doc urls

Advanced Search Column Conditions

This commit fixes an issue we had where the bolding on the Ticket Number and Subject columns of advanced searches showed the opposite of what they should have. We instead want them to be bold if the Tickets are Unanswered.

- Let validate_actions pass if we are trying to disable/archive a Help Topic so that the filter flag can be set.
- Make sure we do not throw validation errors when deleting a filter action. Just delete it.

Only use field display when fetch value is not string

Retain Help Topics for Emails