Metadata Filter with numeric fields without ranges not working with other filters (master only)
wladimirleite opened this issue · 5 comments
I found this issue looking for images with the same width in a real case.
When a numeric field is used to filter items in the metadata panel and the scale is set to "no range" (i.e. exact numeric values are used), the results are correct if no other filter is applied.
However, when I combine it with other filters (in the real case, I was filtering items with no bookmark), the results are wrong (completely wrong items or perhaps no items are shown).
The count shown in the metadata panel (in parentheses after the value) is correct, but the items shown in the main table are wrong.
The problem may be related (or at least similar) to one reported in #2251, but I am not sure.
Putting some debug messages, it seems that the correct set of items are submitted to the function which counts the item per range/value. But when one range/value is selected, it asks for the n-th value (based on the filtered results) and then gets the items associated with the n-th value without filters, which may be different.
Working fine, with only metadata filter applied:
Combined with a bookmark filter, the count is correct, but results are wrong.
There is only one image in bookmark "B" with 1024 pixels of width. Results are showing images with 800 pixels of width.
It is possible to reproduce the issue with any numeric integer field.
Just in case, a sample set of images with different dimension, which helped me testing:
sample-images.zip
Thanks @wladimirleite for reporting, have you already found a fix? If not, @patrickdalla could you please also take a look at this? I think it is probably related to the filtering refactoring.
Thanks @wladimirleite for reporting, have you already found a fix?
I tried to find a quick way to fix it, but unfortunately I couldn't.
Hi @wladimirleite , I think this issue could be caused by the same cause of the issue 2251. I will not be able to review the code till monday. So, please, check if the issue was solved by the same commit that solved 2251, and if not, I will review the code later.
The problem with this caching was that it was caching the order the user applied the filter. So I had to remove it to enforce the original order.
Hi @wladimirleite , I think this issue could be caused by the same cause of the issue 2251. I will not be able to review the code till monday. So, please, check if the issue was solved by the same commit that solved 2251, and if not, I will review the code later.
This issue was also solved by the fix you made to #2251. Thanks @patrickdalla!!!