Redmine

After investigating, it seems like the search displays 10 issues and the next page button displays issues based on date (as indicated by the last document date and the URL reflecting that date). You would expect it to just display the next 10 results in the search regardless of their creation date (like the filter does). It seems that the search has a number limit (to speed up the search) then sorts them by date. Subsequent searches use the last found issue date and run the search again. The search returns issues that are not sorted by date and newer issues could show up after the search limit and would get filtered out because the last issue on the previous page had an older time. To solve this problem, we sort the entire search result by date not just the limited search result:
We fixed it by commenting out line 77 in search_controller.rb

         r, c = s.singularize.camelcase.constantize.search(@tokens, projects_to_search,
           :all_words => @all_words,
           :titles_only => @titles_only,
# do not limit the number of search results as we need the full search set to sort properly         :limit => (limit+1),
           :offset => offset,
           :before => params[:previous].nil?)
         @results += r
         @results_by_type[s] += c
       end

I believe #15987 is a duplicate of this issue.

This is really important for us. The search isn't usable for us if we search for items which results in 1000+ Results.

Search pagination is just plain broken. The fundamental problem is that it hinges on the idea that no two 'objects' will have the same exact timestamp so that timestamp+ will always get the next page of results. As long as duplicate items land in the middle of the pagination block, the data will be displayed. But as soon as a set of duplicates appears on the modulo-10 boundary, you are left without full access to the results.

There are no guarantees that dups can be avoided. A heavily-trafficked system could have multiple users creating issues/wikis/etc with the same exact date. But even on a single-user system, the ability to bulk upload attachments, files, and DMSF docs will leave them all with the same identical date.

Darth's fix is not the full solution. There are 3 things that could be done:

1) Change the search pagination to use the same page size(s) as used for Issues display. Instead of hardcoding at 10, use the value in the Redmine Admin Settings to support multiple pagination limits. That way, the user can at least dynamically play with the boundaries upon which the search results will fall. What may not be displayed at mod-10 or mod-20 may become visible at mod-25. This fix may not be that difficult, and is perfectly inline with UI consistency.

2) Alter the upload function used in DMSF and for attachments/files/docs such that each file has a slight time offset rather than all in the batch being the same. (This will address the bulk import process, but does not solve for multi-user activity on a high-traffic site.)

3) The real solution: fundamentally change the way Search works. Treat a search as a complete record-set, cached by the client, and paginate over the fixed-in-time result rather than querying anew (with offset) for each next page.

I see that the related feature #18631 is closed, Resolution: Fixed.

Is there anything remaining on this Defect #16239?