#7544 closed defect (fixed)
Pagination in ticket query doesn't work when no constraints are defined
Reported by: | Remy Blank | Owned by: | Remy Blank |
---|---|---|---|
Priority: | low | Milestone: | 0.11.2 |
Component: | general | Version: | 0.11-stable |
Severity: | minor | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Go to "View Tickets", "Custom Query", remove all constraints, set the number of items per page to 10 and click "Update". A list of tickets is shown, with more than one page available.
Execute a refresh in the browser, and only the first page remains. All other pages have disappeared. The same happens if one of the links to the next pages is clicked.
This is due to the WHERE clause generated for queries with no constraints but with a list of tickets in the session data.
Attachments (1)
Change History (4)
by , 16 years ago
Attachment: | 7544-unconstrained-query.patch added |
---|
comment:1 by , 16 years ago
Constrained queries have a WHERE clause that looks like this right after an update:
WHERE COALESCE(t.type,'')='defect'
and after a refresh:
WHERE COALESCE(t.type,'')='defect' OR id in (1,2,3)
In the case of unconstrained queries, there is no WHERE clause after an update, but after a refresh it looks like this:
WHERE id in (1,2,3)
This is not correct, it should actually be:
WHERE 1 OR id in (1,2,3)
And this can be simplified to not having a WHERE clause at all. The patch above does exactly that.
Comments?
Patch against 0.11-stable fixing pagination for unconstrained queries