Updating unchanged notification via API with users returns 200 instead of 304

[rndmh3ro]

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: https://github.com/Icinga/icingaweb2-module-director/issues/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)

1. Create a user called testuser.

2. create a file data2.json with 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"
   ]
   }

3. 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"
   ]
   }

4. 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