Thanks for reporting 👍 I see the same issue on Nextcloud 19.

cc @juliushaertl @blizzz as 'httpd/unix-directory' is not a pattern they cannot use matches as operator. We should probably hide operators which are not compatible to each other. We have the same issue the other way around for File MIME type is Office Documents.

Hi since the number of reported issues at the workflow_ocr app regarding this problem is increasing i'd kindly like to ask what are the plans for this? If we like to implement #23666 (comment) i can try to do this if you're willing to accept my PR ? 😃

cc @juliushaertl @blizzz @kesselb

can try to do this if you're willing to accept my PR

Cool 👍

since the number of reported issues at the workflow_ocr app

A pinned FAQ issue might help with that. At least here at nextcloud/server it helps a bit.

A pinned FAQ issue might help with that. At least here at nextcloud/server it helps a bit.

Thanks for the hint, will give it a try 😄

So basically i'd implement it the following way (given that the first column is set to File MIME type):

• The entries of third column (containing the the filetype) are filtered with respect to the second columns choice (comparator)
• If the user sets the comparator to is or is not the filetypes Folder, PDF Documents and Custom mimetype will be shown in the third column
• If the user sets the comparator to matches or does not match the regex based types Images and Office documents will be shown in the third column

Would that be the way to go @kesselb ?

@R0Wi generally that sounds good to me.

On a second thought, it is quite technical for the end user. An admin might now about regex's and stuff, but for the average user "is (not)" or "matches (not)" or the meaning of it is black magic. The best way would be to eliminate the differences (only keep is _(not)) and figure out what is desired by testing the third columns value.

That would be a bigger change however, and not backportable. This is an advantage of your suggestion, so let's go with it.

Changing the UI more radically (it has effects on the backend bits, too) could be something for 22.

I suppose this is still valid on NC21.0.2?

AFAIK unfortunately yes. Did not manage to create a PR, yet 😢

NC 21.0.3 Workflow OCR 1.21.1, the problem still persists.

The only way to deal with this, for now, is to remove the other conditional, in my case, it was file MIME = pdf.
As I wanted it to ocr just files created/modified with 2ocr somewhere in its name (insert /2ocr/i in the box), it is usable for now.

@kesselb did you ever get around to doing this?
still seems to be an issue though luckily after reading this, changing it to "is" instead of matches works for me but the error is not very intuitive

Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!

My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!

If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+

I dont have an issue with this anymore in general as after reading all this back when I had the issue I just know what I need to click and what that error actually means...
However I would love to help as far as I can...
I just tested this on 25.0.3 and selected "matches" PDF and it tells me that the regular expression is invalid.

Actually, when you choose "custom MIME type" you are facing a similar error. But this is a bogus user-interface: the placeholder suggests that you just can add "e.g. http/unix-directory". However, the placeholder suggestion is wrong, you need to enter a full-fledged regular expression, i.e. http/unix-directory does not work, but something like |http/unix-directory|.

I have no problems with entering a regular expression, but neither the placeholder nor the cryptic error message The given regular expression is invalid are of any help for directing the struggling user into the right direction.

I experienced this with a up-to-date v25 NC. Screenshots are appended

Still valid for NC 27.1.3