Sounds reasonable to me.
Previous (un)acknowledges may not be affected.
Maybe it could makes sense not to allow this for everyone or every host (user type and/or group permissions?).

when looking into this, ability to notify on acks (a feature request) should be kept in mind. un-acking should result in some track record being kept anyway

I scratched my head on this, looking for a way to unack until Volker told me this was not implemented.

Ideally, users that can ack should be able to unack.

I think such a feature where you can un-acknowledge a trigger which will restart the action/escalation steps would be very useful. I often see users bulk acknowledge everything and erroneously ack unrelated events.

I also looking for this function, human mistake is a issue, some event need time to solve, or wait for solution, but people may forget about the event, so if have function to remove the acknowledge and/or time out mechanism for acknowledge, it can help for these issue.

I've been looking for this as well. It's particularly interesting in large systems where there's a lot of sysadmins and not all agree on what's important or not. I've removed some acks from the db itself, but that's not really a clean solution. Please add this - I'd guess it shouldn't be too much work needed.

When testing notifications about problem update (acknowledge, unacknowledge, adding a message, changing problem severity, closing) note that the notifications are not sent to the author of update. I could not find this "business rule" in documentation.

So, to test notifications it is necessary to either create another user for receiving notifications or patch/recompile server by commenting out 2 lines like

--- a/src/zabbix_server/escalator/escalator.c
+++ b/src/zabbix_server/escalator/escalator.c
@@ -717,8 +717,8 @@ static void add_sentusers_ack_msg(ZBX_USER_MSG **user_msg, zbx_uint64_t actionid
                ZBX_DBROW2UINT64(userid, row[0]);
 
                /* exclude acknowledgement author from the recipient list */
-               if (ack->userid == userid)
-                       continue;
+//             if (ack->userid == userid)
+//                     continue;
 
                if (SUCCEED != check_perm2system(userid) || PERM_READ > get_trigger_permission(userid, event))
                        continue;

Available (server part) in development branch feature/ZBXNEXT-1882-4.5 (pull request).

Currently to test this feature the frontend and API changes must be taken from other development branch - feature/ZBXNEXT-5865-4.5.

Available in versions:

• pre-5.0.0rc1 7959b31358

Documentation updated:

• Problem update
• What's new

API documentation pages updated:

• Appendix 2. Changes from 4.4. to 5.0
• 5.0 event.acknowledge Parameters section
• 5.2 event.acknowledge Parameters section