Issue #4750 was never actually resolved. The same behaviour continues to show up in v1.11 - v1.12.2.
The update referenced in #4750 fixes the issue, can it be included in releases please?
@asmith3006
The fix you referenced is not the way we see the counts working...he basically copied the functionality from the other methods. If you look at this commit message you can see the idea we have is to rewire the pagination system to dynamically add pages until it comes up with a short read of results. Don't worry, we will address this in due time.
Cheers.
Still not working.
/include/class.search.php already has
function getCount($agent, $cached=true) {
$count = null;
if ($cached && ($counts = self::counts($agent, $cached)))
but osTicket 1.12.3 still does not return more than 500 results in search

@stf675
Please read my message above. We will need to rewire the pagination system. We will address this in due time.
Cheers.
Why we show 500 most relevant results on keyword searches...
osTicket, by default, uses MySQL FULLTEXT to index search results. The downside is that - the index is highly dependent on user-tuned MySQL server parameters such stop words...etc... which are obviously outside osTicket scope.
By the nature of how FULLTEXT works - the relevance score of the matches is critical. How the score is assigned is beyond the scope of this post but a good read on learning how to fine-tune searches. Based on the key words entered, it can be downright irrelevant pages of results (which resulted in a lot of complains before) and more importantly very expensive to get counts for pagination. For this reason we decided to limit the results to 500 based on relevance.
_Why the number 500?_ No good reason really other than after some experimenting we felt like that is good enough result set. Perhaps we can make it configurable, but I simply wanted to demystify and point out the history of the limit.
is there any other way to have ticket data exported into CSV? (without limiting to 500 results)
@stf675
Not at this time, no. The only other way would be to modify the code to remove the limit or export via the database in CSV format.
Cheers.
Why we show 500 most relevant results on keyword searches...
osTicket, by default, uses MySQL FULLTEXT to index search results. The downside is that - the index is highly dependent on user-tuned MySQL server parameters such stop words...etc... which are obviously outside osTicket scope.
By the nature of how FULLTEXT works - the relevance score of the matches is critical. How the score is assigned is beyond the scope of this post but a good read on learning how to fine-tune searches. Based on the key words entered, it can be downright irrelevant pages of results (which resulted in a lot of complains before) and more importantly very expensive to get counts for pagination. For this reason we decided to limit the results to 500 based on relevance.
_Why the number 500?_ No good reason really other than after some experimenting we felt like that is good enough result set. Perhaps we can make it configurable, but I simply wanted to demystify and point out the history of the limit.
The 500 results are not very useful when searching for more than one word in the search. Example: "good day" will return results for all tickets containing "good" and tickets containing "day". But I don't want that. I want specifically "good day". Please tell me how I can search an exact phrase only.
Also, how do I search for two words in a ticket but not an exact phrase aka _contains all words_ ?
@jakeulc - I think this is perhaps a misunderstanding on how full text search works - stop words (space in this case) are there to split the phase into words for contextual search.
If you need multi keyword exact match then you must quote the term. Searching for "Good day" (quoted) will give you the desired results. This is similar to _operators_ google supports.
Sorry I don't understand the solution to searching _contains all words_
Most helpful comment
Why we show 500 most relevant results on keyword searches...
osTicket, by default, uses MySQL FULLTEXT to index search results. The downside is that - the index is highly dependent on user-tuned MySQL server parameters such stop words...etc... which are obviously outside osTicket scope.
By the nature of how FULLTEXT works - the relevance score of the matches is critical. How the score is assigned is beyond the scope of this post but a good read on learning how to fine-tune searches. Based on the key words entered, it can be downright irrelevant pages of results (which resulted in a lot of complains before) and more importantly very expensive to get counts for pagination. For this reason we decided to limit the results to 500 based on relevance.
_Why the number 500?_ No good reason really other than after some experimenting we felt like that is good enough result set. Perhaps we can make it configurable, but I simply wanted to demystify and point out the history of the limit.