Data-driven Categories: Invert Filter not working as expected

[axel.hennig]

I'm not sure, if this is by design or if this is a bug, but it is definitely not what I've expected.

Steps to reproduce:

• Three JPG-files with filled CameraOwnerName (XMP::exifEX\CameraOwnerName\OwnerName\0). The three files and CameraOwnerNames are:
  • 1.jpg: Alice
  • 2.jpg: Bob
  • 3.jpg: Chris
• Setup a Data-driven Category with (only listing what I've entered or changed):
  • Basic Settings - Tag: XMP::exifEX\CameraOwnerName\OwnerName\0
  • Basic Settings - Category Filter: @All|^0 work with$ (this Category contains just the three files mentioned above)
  • Formatting - Use 'Other' element: No
  • Replace and Filter - Filter Pattern: Alice;Bob

The result of this Data-driven Category is: Two Sub-Categories, namely 'Alice' and 'Bob' (both containing just one file). This is what I've expected.

Now comes the part that I do not understand.

Steps to reproduce:

• Open the Data-driven Dialog-box again (the Dialog-box of the above created Data-driven Category).
• Just change: Replace and Filter - Invert Filter: Yes

The hint in the Data-driven Dialog-box for 'Invert Filter' is: Invert the result of the filter, using only values not matching the filter.

The result of this changed Data-driven Category is now: Three Sub-Categories, namely 'Alice', 'Bob' and 'Chris'. My expectation was that just 'Chris' appears (invert the result of the filter) and not everything.

[Mario]

I'll have a look for one of the next releases. I'll move this into bug reports (it sounds like a bug report) so I can track it.

[Mario]

Well, that was easy to repro and fix.
The culprit was that multiple filers were applied (Alice and Bob).

When the filter is not inverted, when the value(s) fetched from the database match any of the filters, we have a match.
When the filter is inverted, each regular expression must be applied and only when none of them matches, the value is applicable. This was not correctly implemented. 

Fixed for the next release. A glitch that goes back many years. Probably no other ever used this specific combination of settings before.

[axel.hennig]

Thanks for fixing.

[Mario]

You're welcome. This was one of the bugs that lies dormant for many years, until a user selects a combination of options that reveals it. I have fixed the bug and updated my tests.

[PandDLong]

Thanks for fixing.

I did have a similar issue but I assumed it was operator error and it wasn't critical so I didn't bother posting about it.  

I look forward to the next release and re-attempting a couple of data-driven categories.

Michael

[Mario]

If you find something that does not work, just ask in General Questions. I can try to repro it when there is time and see if it is a bug, if you do something wrong or, sometimes, if something is just not possible. Not all fringe cases can, or should, be handled. Sometimes it's just too expensive and creates too much maintenance debt to implement every possible variation of something.