Fix form validation with equal and in operator for adding expression with group to filter #2750
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2750 +/- ##
=======================================
Coverage 55.52% 55.52%
=======================================
Files 567 567
Lines 41172 41175 +3
=======================================
+ Hits 22861 22864 +3
Misses 18311 18311 ☔ View full report in Codecov by Sentry. |
| validated_data["value"] = "|".join(value) | ||
| elif operator_type == Operator.EQUALS: | ||
| validated_data["value"] = value[0] |
There was a problem hiding this comment.
You could do early returns. If you plan one for every operator_type this order is good, since EQUALS and IN are the most common (exists for the most match_fields).
There was a problem hiding this comment.
If there are other cases of match_fields behaving oddly you can split out handling of those too, like for ip-addresses. Isolate 'em!
There was a problem hiding this comment.
The odd ones are "ip_address", "severity" and "sysname". "sysname" can do partial string matching, "severity" does numerical comparison. They're both candidates for their own methods.
There was a problem hiding this comment.
It does look to me that the actual cleaning for "sysname" and "severity" will look identical to EQUALS. If you do an early return after IN you could remove the "if" for EQUALS and just do value = value[0]. "severity" might need casting to int but that should be it!
|
Kudos, SonarCloud Quality Gate passed!
|
johannaengland
deleted the
bugfix/alertprofiles/add-group-to-expression
branch
This was caused by #2667. It changed how the values are saved (as
['AD']for example instead of'AD'). This shows again, that we need even more tests for the alert profiles views.Thanks to @runeki for finding this bug!