[//]: # (werk v2)
# notification_rule: cancel previous notifications now working with custom plugin scripts
key | value
---------- | ---
date | 2024-01-31T15:15:29+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
When creating or updating notification rules, the option to "cancel_previous_notifications"
was previously not available when the plugin name selected was a custom plugin script.
This werk addresses this issue and now allows for custom plugin scripts when setting the
option to cancel.
[//]: # (werk v2)
# agent_bakery: mk_postgres.py: restore required keys
key | value
---------- | ---
date | 2024-02-01T06:19:27+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
[Werk #15645](https://checkmk.com/werk/15645) made the Inputs of "Instance
settings" of the Agent rule "PostgreSQL database and sessions (Linux, Windows)"
optional by accident. If you did not specify all keys, baking agents failed with
a `KeyError` on the automation call.
[//]: # (werk v2)
# authentication: remove user profile dir when unknown user and failed to login
key | value
---------- | ---
date | 2024-01-26T15:59:51+00:00
version | 2.3.0b1
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Previously, failed login attempts with an unknown user would create a
user profile directory. This is no longer the case. The profile
directory is now only created for valid users.
[//]: # (werk v2)
# netapp_ontap_psu: fix discovery ruleset
key | value
---------- | ---
date | 2024-01-31T13:08:07+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | no
This problem affected users who wanted to discover the 'summary' mode of PSU service: it was not possible to configure the appropriate discovery rule. This werk fixes this behaviour.
A rediscovery is required for the change to take effect.
[//]: # (werk v2)
# tag_group: change the identification field from 'ident' to 'id'
key | value
---------- | ---
date | 2024-01-29T13:13:54+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
Before this Werk, when creating a tag group, the **ident** field was used to provide its identification as well as that of the tags associated to the group, however the information was returned in the **id** field. This Werk unifies the names and now the **ident** fields are renamed to **id**. Users should adapt their scripts accordingly.
For comptatibility reasons CheckMK 2.2.0 and 2.3.0 will support both **id** and **ident**, but **ident** will be removed on the next version.
The following example shows the changes that need to be applied to the payload to use this endpoint:
Original payload:
```json
{
"ident": "test_group",
"title": "Test group",
"help_text": "My test groupd",
"tags": [
{"ident": "test", "title": "Test Tag"}
]
}
```
Updated payload:
```json
{
"id": "test_group",
"title": "Test group",
"help_text": "My test groupd",
"tags": [
{"id": "test", "title": "Test Tag"}
]
}
```
Werk 15694 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Remove mod_auth_mellon
Class: feature
Compatible: incomp
Component: omd
Date: 1693380015
Edition: cre
Knowledge: undoc
Level: 1
Version: 2.3.0b1
With Checkmk 2.2, announced by Werk #14977, the usage of mod_auth_mellon was deprecated. This release now removes mod_auth_mellon.
If you still have mod_auth_mellon in your apache config, the apache service will not be able to start.
Errors are logged to <tt>var/log/apache2/error_log</tt>.
If you want to continue to use SAML you can do it in the Enterprise Edition via <i>Setup -> Users -> SAML connections</i>.
------------------------------------<diff>-------------------------------------------
Title: Remove mod_auth_mellon
Class: feature
Compatible: incomp
Component: omd
Date: 1693380015
Edition: cre
Knowledge: undoc
Level: 1
Version: 2.3.0b1
With Checkmk 2.2, announced by Werk #14977, the usage of mod_auth_mellon was deprecated. This release now removes mod_auth_mellon.
If you still have mod_auth_mellon in your apache config, the apache service will not be able to start.
- Errors are logged to <tt>var/lib/apache2/error_log</tt>.
? ^^
+ Errors are logged to <tt>var/log/apache2/error_log</tt>.
? ^^
If you want to continue to use SAML you can do it in the Enterprise Edition via <i>Setup -> Users -> SAML connections</i>.
Werk 16384 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# notification rule: allow for non builtin service levels
key | value
---------- | ---
date | 2024-01-17T11:19:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level": "gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
"value": {"from_level": 10, "to_level": 20}
}
}
```
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# notification rule: allow for non builtin service levels
key | value
---------- | ---
date | 2024-01-17T11:19:06+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When configuring a notification rule via the Rest API, you could not
set the value for "match_service_levels" to anything but the default
service levels. This werk addresses this issue by now allowing any
of the service levels configured to be used. This change mean that
there is a change to the request schema. Previously, we accepeted
the service level string value, whereas now we accept the integer
value.
Previous schema
```
{"match_service_levels": {
"state": "enabled",
"value": {"from_level": "silver", "to_level": "gold"}
}
}
```
New schema
```
{"match_service_levels: {
"state": "enabled",
- "value": {"from_level" 10, "to_level": 20}
+ "value": {"from_level": 10, "to_level": 20}
? +
}
}
```