Ticket #7544 (closed defect: fixed)
Opened 3 years ago
Last modified 3 years ago
Pagination in ticket query doesn't work when no constraints are defined
| Reported by: | rblank | Owned by: | rblank |
|---|---|---|---|
| Priority: | low | Milestone: | 0.11.2 |
| Component: | general | Version: | 0.11-stable |
| Severity: | minor | Keywords: | |
| Cc: | |||
| Release Notes: | |||
| API 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
Change History
Changed 3 years ago by rblank
- Attachment 7544-unconstrained-query.patch added
comment:1 Changed 3 years ago by rblank
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?
comment:2 Changed 3 years ago by rblank
- Resolution set to fixed
- Status changed from new to closed
Patch applied in [7505].
comment:3 Changed 3 years ago by rblank
Closed #7523 as a duplicate.



Patch against 0.11-stable fixing pagination for unconstrained queries