Filtered hostgroup, double filter in detail pane

[gbin2265]

Describe the bug

If I use the link hostrgroups and then go to the HOST or SERVICES detail everything works perfectly.

If I filter a hostgroup by a certain name and then press the HOST or SERVICES link, the list in the detail pane is empty.

When I look at the URL I see that the filter is placed twice after the hosts.

To Reproduce

icingaweb2/icingadb/hostgroups?hostgroup.name=icinga_servers#!/icingaweb2/icingadb/hosts?hostgroup.name=icinga_servers&hostgroup.name=icinga_servers
Why 2 times -> hostgroup.name=icinga_servers&hostgroup.name=icinga_servers

If I replace the = with ~ in the hostgroup filter:

icingaweb2/icingadb/hostgroups?hostgroup.name~icinga_servers#!/icingaweb2/icingadb/hosts?hostgroup.name=icinga_servers&hostgroup.name~icinga_servers
Why 2 filters -> hostgroup.name=icinga_servers&hostgroup.name=icinga_servers

Expected behavior

I assume that only the filter has to be hostgroup.name=icinga_servers
and that the filter that was provided with the hostgroup is not extra added to the host/service detail pane

Your Environment

Latest snapshot on 17Feb2024

PHP : 8.3 (Remi)
OS : RHEL 7

icinga-l10n.noarch                  1.3.0+9.g1eb336e9-1708117586.el7   
icinga-php-common.noarch            1.0.0165655404400000000-0.20220630.0154.el7.icinga
icinga-php-library.noarch           0.13.1+4.g7d54fbd-1702674329.el7   
icinga-php-thirdparty.noarch        0.12.1+3.g2eeed31-1702674368.el7   
icingacli.noarch                    2.12.1+6.gd6881e027-1708121005.el7 
icingaweb2.noarch                   2.12.1+6.gd6881e027-1708121005.el7 
icingaweb2-common.noarch            2.12.1+6.gd6881e027-1708121005.el7 
php-icinga.noarch                   2.12.1+6.gd6881e027-1708121005.el7 

icingadb-web.noarch                 1.1.1+0.g274b903c-1708124776.el7   

icinga2-bin.x86_64                  2.14.2+126.g7d1c887a3-1708121006.el7
icinga2-common.x86_64               2.14.2+126.g7d1c887a3-1708121006.el7
icinga2-ido-pgsql.x86_64            2.14.2+126.g7d1c887a3-1708121006.el7

[gbin2265]

!! I see now that this problem is also for the SERVICEGROUPS.

[nilmerg]

This requires a breaking change in our framework, so won't happen in a minor.