icingaweb2-module-director
icingaweb2-module-director copied to clipboard
Icinga
Modification of multiple individual services not possible after upgrade to version 1.9.0
Expected Behavior
In Version 1.8.x and befor it was possible to search for individual service checks and select multiple services. Then you was able to modify or delete the selected services.
Current Behavior
After upgrading to version 1.9.0 if we selcet multiple services, there is just only one of them selected for modification. So there is no chance to modify multiple services at once.
Possible Solution
Maybe there is a issue between uuid and service names?
Steps to Reproduce (for bugs)
Director -> Services -> single Service -> search for service -> select services on different hosts - on new tab "multiple objects" showing just one item for modification
Your Environment
- Director version (System - About): 1.9.0
- Icinga Web 2 version and modules (System - About): 2.9.6
- Icinga 2 version (
icinga2 --version): 2.12.6 - Operating System and version: RHEL 7.9
- Webserver, PHP versions: 7.3.29
I haven't been able to reproduce this with v1.9.1, can you please give it a try?
Dear Thomas, we have implemented the director in Version 1.9.1 and restarted the icinga-director.service, but the problem still exists. If we want to modify or delete multi-selected individual service checks with the same name only one of them is editable.
We can reproduce this issue in 1.9.1. It occurs when we mark services with same servicename on different hosts. If you mark services with different names it works fine.
I haven't been able to reproduce this with v1.9.1, can you please give it a try?
@Thomas-Gelf we can reproduce this bug. Also the older "/icingaweb2/director/services/edit?((id=146)|(id=179)|(id=178))" does not work anymore, it creates an "icinga_service has a multicolumn key, array required". Please have a look at this.
@akqopensystems maybe change the topic of the issue to "[...] multiple individual services with the same name[...]", to make it more obvious. I think its important to highlight that the problem does only exist with the same service_names, not when service_name is different.