Werk #20020: Rule editor and API no longer hide an empty explicit hosts/services condition
| Component | Setup | ||||||
| Title | Rule editor and API no longer hide an empty explicit hosts/services condition | ||||||
| Date | Jul 21, 2026 | ||||||
| Level | Prominent Change | ||||||
| Class | Bug Fix | ||||||
| Compatibility | Incompatible - Manual interaction might be required | ||||||
| Checkmk versions & editions |
|
Previously, if a rule's "Explicit hosts" or "Service" condition was saved with an empty list - a valid, deliberate condition meaning the rule matches no host or service - both the rule editor and the REST API silently treated it as if no condition were set at all.
In the rule editor, opening such a rule showed the "Explicit hosts"/"Service" checkbox as
unchecked, hiding the fact that a (now pointless) condition existed. In the REST API, a
GET on such a rule omitted the condition from the response entirely.
This was more than a display issue: saving the rule again - either by clicking Save in
the editor without any other changes, or by feeding the API response back into a PUT/
POST - persisted the rule with no condition at all, silently turning it into a rule
that applies to every host or service instead of none.
The rule editor and REST API now correctly represent an empty explicit hosts/services condition as such.
If you have a rule already in this state, you'll notice two changes after upgrading:
- The ruleset overview already flags such rules with "This rule does never apply due to an empty list of explicit hosts!" - use that to find them.
- Opening one of these rules and clicking Save (even with no other changes) is now blocked with "Please add at least one host."/"Please add at least one service pattern.", instead of silently succeeding. To fix it, either add at least one host/service pattern back to the condition, or uncheck the condition entirely if you meant for the rule to apply without restriction, or disable/delete the rule if it's no longer needed.