Regex filter including commas not working as expected about autobrr

[jjxxs]

@zze0s the linked PR won't fix this issue. for the given example, the function introduced in 41811dc will produce the following output:

\.[Ss]\d{1
3}E\d{1
3}\. 

also the linked commit will introduce new issues when escaped brackets are used, e.g. \(,txt will not split the regex at the comma.

i would suggest to either let the user use '|' to separate their expressions or extend the UI so that the user can hit a '+' button and a new input-box will appear to enter another regex.

[zze0s]

@zze0s the linked PR won't fix this issue. for the given example, the function introduced in 41811dc will produce the following output:

\.[Ss]\d{1
3}E\d{1
3}\. 

also the linked commit will introduce new issues when escaped brackets are used, e.g. \(,txt will not split the regex at the comma.

i would suggest to either let the user use '|' to separate their expressions or extend the UI so that the user can hit a '+' button and a new input-box will appear to enter another regex.

Yeah, aware that that PR needs some more work, but it's a start. The current filters are broken with as is if using regex and comma in there, so there's nothing to break in that sense.

Pipes are also valid inside regex patterns so that is not an option to use as a splitter either.

Having multiple inputs would be ideal and I do consider the filters a design flaw in hindsight.
We have talked about building more of a "rules engine" where you can build the expressions with a nice ui or some expression meta language. Doing that is no small task tho so a quick fix for now would be preferred.

[jjxxs]

I think the main issue is that the filters currently accept two different kinds of input:

• a simplified format where '*' and '?' can be used as wildcards [1]
• a regex when the 'use regex'-option is set

Ideally the backend would use two different filter-functions, depending of the state of the 'use regex'-option. Luckily that's what the backend already does:

autobrr/internal/domain/filter.go

Lines 302 to 319 in 17e9720

	if f.UseRegex {
	if f.MatchReleases != "" && !matchRegex(r.TorrentName, f.MatchReleases) {
	f.addRejectionF("match release regex not matching. got: %v want: %v", r.TorrentName, f.MatchReleases)
	}
	if f.ExceptReleases != "" && matchRegex(r.TorrentName, f.ExceptReleases) {
	f.addRejectionF("except releases regex: unwanted release. got: %v want: %v", r.TorrentName, f.ExceptReleases)
	}
	} else {
	if f.MatchReleases != "" && !containsFuzzy(r.TorrentName, f.MatchReleases) {
	f.addRejectionF("match release not matching. got: %v want: %v", r.TorrentName, f.MatchReleases)
	}
	if f.ExceptReleases != "" && containsFuzzy(r.TorrentName, f.ExceptReleases) {
	f.addRejectionF("except releases: unwanted release. got: %v want: %v", r.TorrentName, f.ExceptReleases)
	}
	}

The matchRegex function could be changed to stop splitting on , which breaks the regex. The 'use regex'-option is opt-in and users can and will use | instead the comma to achieve the same effect. Existing filters could easily be migrated on a version-update by replacing the , with a | for filters where the regex-option is set.

This would make the feature work as intended without breaking anything. No workarounds would be needed.

[1] https://autobrr.com/filters#advanced