Updating unchanged notification via API with users returns 200 instead of 304 #2882
Description
Expected Behavior
The API should return 304 instead of 200 when updating a notification that contains a user-field (without changing its params).
Current Behavior
Similar bug as here: #2660
One user also mentions it:
Additionally we have found out that the notification endpoint has also this issue.
When updating a notification via an API-call with POST, it returns 200 instead of 304.
This worked in 1.8.1 but does not work in 1.11.1
Steps to Reproduce (for bugs)
- Create a user called
testuser. - create a file
data2.jsonwith the contents:
{
"apply_to": "service",
"assign_filter": "host.groups=%22Live%22&!service.vars.nocall=%22yes%22&service.vars.onlycrit=%22yes%22&!service.display_name=%22f5_pool_/stage/%2A%22",
"imports": [
"test"
],
"notification_interval": 0,
"object_name": "service_warn",
"object_type": "apply",
"states": [
"Warning"
],
"types": [
"Problem"
],
"users": [
"testuser"
]
}
- run the following curl-command to create the notification:
> curl -v -X PUT --data @data2.json -H "Accept: application/json" -L -u icingaadmin:icinga http://localhost:8083/icingaweb2/director/notification
* Trying 127.0.0.1:8083...
* Connected to localhost (127.0.0.1) port 8083 (#0)
* Server auth using Basic with user 'icingaadmin'
> PUT /icingaweb2/director/notification HTTP/1.1
> Host: localhost:8083
> Authorization: Basic aWNpbmdhYWRtaW46aWNpbmdh
> User-Agent: curl/7.81.0
> Accept: application/json
> Content-Length: 424
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Date: Fri, 19 Apr 2024 09:05:35 GMT
< Server: Apache/2.4.57 (Debian)
< Content-Length: 443
< Content-Type: application/json
<
{
"apply_to": "service",
"assign_filter": "host.groups=%22Live%22&!service.vars.nocall=%22yes%22&service.vars.onlycrit=%22yes%22&!service.display_name=%22f5_pool_/stage/%2A%22",
"imports": [
"test"
],
"notification_interval": 0,
"object_name": "service_warn",
"object_type": "apply",
"states": [
"Warning"
],
"types": [
"Problem"
],
"users": [
"testuser"
]
}
- run the following command to update the user without changing any of its parameters. Notice that it returns a 200 instead of 304.
> curl -vv -X POST --data @data2.json -H "Accept: application/json" -L -u icingaadmin:icinga http://localhost:8083/icingaweb2/director/notification?name=service_warn
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 127.0.0.1:8083...
* Connected to localhost (127.0.0.1) port 8083 (#0)
* Server auth using Basic with user 'icingaadmin'
> POST /icingaweb2/director/notification?name=service_warn HTTP/1.1
> Host: localhost:8083
> Authorization: Basic aWNpbmdhYWRtaW46aWNpbmdh
> User-Agent: curl/7.81.0
> Accept: application/json
> Content-Length: 424
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 19 Apr 2024 09:05:43 GMT
< Server: Apache/2.4.57 (Debian)
< Content-Length: 443
< Content-Type: application/json
<
{
"apply_to": "service",
"assign_filter": "host.groups=%22Live%22&!service.vars.nocall=%22yes%22&service.vars.onlycrit=%22yes%22&!service.display_name=%22f5_pool_/stage/%2A%22",
"imports": [
"test"
],
"notification_interval": 0,
"object_name": "service_warn",
"object_type": "apply",
"states": [
"Warning"
],
"types": [
"Problem"
],
"users": [
"testuser"
]
}
Your Environment
- Director version (System - About): 1.11.1
- Icinga Web 2 version and modules (System - About): 2.12.1
- Icinga 2 version (
icinga2 --version): - Operating System and version: debian 12
- Webserver, PHP versions: Apache/2.4.57