Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

@blizzz I rebased this against the current master and adjusted to code to work with c24ead8.

Would be happy to see a review of this since me and other users are stumbling across the described issue regularly 😄

@susnux may I kindly ask you for a review, please?

@come-nc the failing cypress tests seem to be unrelated? AFAIK there are no workflowengine E2E tests ...

The more I think about this the more I think we should simply only allow matches/!matches operator for mime types. If the custom value is only possible for regex anyway, we should require a regex always. It’s the most powerful thing and it will be less confusing.

The more I think about this the more I think we should simply only allow matches/!matches operator for mime types. If the custom value is only possible for regex anyway, we should require a regex always. It’s the most powerful thing and it will be less confusing.

Would need repair steps however, and might be more confusing to those not knowing regex. Also end user might be using this.

The more I think about this the more I think we should simply only allow matches/!matches operator for mime types. If the custom value is only possible for regex anyway, we should require a regex always. It’s the most powerful thing and it will be less confusing.

Would need repair steps however, and might be more confusing to those not knowing regex. Also end user might be using this.

Maybe we could combine both approaches:

• Use regex under the hood for all predefined mimetypes
• For custom mimetype instead of making a distinction via is/!is and matches/!matches, we would always use match/!matches and could add a little checkbox next to the custom mimetypes text field called Regex. If it's checked, we would expect a valid regex in the text box. If not, the user could use a regular string (so an exact match in the end). In the backend we could again map the latter internally to an regex. Something like my/mimetype would become /^my\\/mimetype$/. The mapping should both cover start and end tokens for the regex (^ and $) as well as some escaping for reserved characters.

Of course repair steps would be needed in any case but I guess it would be worth it. To me this sound like the cleanest solution.

What do you think?

@R0Wi Can we directly show "Custom mimetype" and "Custom regex" as 2 separates options in the drop down?

@R0Wi Can we directly show "Custom mimetype" and "Custom regex" as 2 separates options in the drop down?

I think this should be possible, yes 👍 Pretty good idea. Do you want me to change the PR accordingly or are we waiting for further feedback first?

@R0Wi Can we directly show "Custom mimetype" and "Custom regex" as 2 separates options in the drop down?

I think this should be possible, yes 👍 Pretty good idea. Do you want me to change the PR accordingly or are we waiting for further feedback first?

If you can change it that’s great, yeah.
I think it will please everyone. We just have to make sure existing configurations from previous version will correctly be loaded by the UI as well.