Ubuntu 16.04 LTS

Hi,
I was able to confirm the described behavior. Forwarding to the development team - this behavior should either be fixed or documented.

This behavior was intentionally introduced with development of ZBXNEXT-4447.
The main idea behind this decision was: If user wants to perform an action, he should be allowed to perform it for all selected problems.
I agree, that this was not described properly in documentation.

OK... It is possible to automatically close a problem after it has been acknowledged? Currently I have to check every hour if a problem (trap, windows eventlog, other log files) has just been acknowledged and not closed. Otherwise I will not receive any information about new problems.

With version 3 there was the work instruction: With every mass acknowledgment the checkbox "closing" must be activated. Now this is no longer possible.

Personally, I don't think it is a good practice to try to close the problems you should not be able to close.

As a workaround for your problem, I can suggest to add a Tag for triggers, where you are allowing manual close. And before doing mass close of problems, you could filter out only problems, that has the Tag, you have added.
Note, that this will work only for problems that were created after trigger was updated with this Tag.

Faced this recently so let me share some experience from a 24/7 NOC perspective. 

Occasionally there are incidents in monitored environment when huge amount of events are generated in Zabbix, mostly firing rare log triggers with multiple event generation mode and no recovery conditions. Now imagine having to close 10K+ events in Problems page with triggers in mixed order like you suggest. 

As monitoring operator has to clear all that mess, he tries to mass select them all, fails because in the huge list there are not closable problems, gets mad from the error messages, additionally hits URI-too-long webserver errors till finally finds some way to get this all cleared, but the experience was way worse it could have been. 

While at the same time the problems could be all selected and then Zabbix internally would close the ones it can, leaving the non closable open and displaying a relevant message saying "Out of 200 selected problems 172 were closed but 28 can't be closed because they have not configured to be closed manually..."

Thank you, ingus.vilnis for explaining importance of this use-case.

As this currently works as designed, with only problem being badly documented, I would keep this ZBX task as documentation task.

To solve your problem, please create new ZBXNEXT task and put your votes there.

Thank you.

Documentation for "Problem acknowledgement" page updated:

• 4.0 (diff)
• 4.2 (diff)
• 4.4 (diff)

If only creating a ZBXNEXT would solve this problem. For complete user satisfaction you should also include this ink https://www.zabbix.com/development_services

This request was NOT about missing documentation but about lost feature which used to work before. And the way it is currently implemented based on some personal decisions does not align with expectancies how users would like it to work. 

It is really disappointing and also dangerous that misconceived workflows make the acknowledgement so difficult.

@Valdis:

• You have explaint to add a tag. This resolved not my problem to make a mass acknowledge twice: one fore the close able one for the not close able.
• what is your solution to rearm trigges if there are acknowledged like Traps or Logfiles.

You make it really easy in this case: "works as design" and it is not properly documented.

It is not really thoroughly thought out.

Ruddimaster, we once again carefully thought out this functionality. You're right, this should work more friendly. In the next minor version this will be fixed.

Thank you for your feedback.

Alexei, thanks for your openness...

Fixed in development branch feature/ZBX-16031-4.0

Fixed in:

• 4.0.12rc1 ffc8281f75f
• 4.2.6rc1 3d4d3ac3cf7
• 4.4.0alpha2 f1f72b97995

Tthis work great now again...

Many Thanks!!!

Updated documentation:

• What's new: 4.0.12, 4.2.6 
• Updating problems: 4.0, 4.2, 4.4 (description of "Change severity" and "Close problem' options)