A possible solution/workaround for this issue could be to add '(due_date = 1)' to the list of selected columns, but I think the *real* question is, why are we doing a SELECT DISTINCT here ? It does not make much sense to me to do so, as it would appear that a normal SELECT should do the job just fine.

But then again messing with the filter_api always feels like opening a can of worms...

In my opinion, the best option in the long term is to get rid of the DISTINCT.

However, it is also potentially a more hazardous approach; therefore to minimize the risk of introducing a regression in 1.2 branch, I'll follow the more conservative approach of adding an additional column to the select for the sort.

For 1.3 branch, I'll remove the DISTINCT instead, and we can see down the line if that breaks something.

It turns out @maschneider was right... I did some testing on the master branch today, and without the distinct we do get multiple rows, e.g. when filtering bugs having more than one bugnote with text matching the search filter.