upstream/icingadb-web
1
0
Fork 0
mirror of https://github.com/Icinga/icingadb-web.git synced 2026-05-28 04:36:06 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fix empty or incomplete object customvars (#1332)

Browse source 
fixes #1331
This commit is contained in:
Johannes Meyer 2026-03-06 14:23:13 +01:00 committed by GitHub
commit ecfd767000
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 31 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
doc/05-Upgrading.md
View file

@ -3,6 +3,31 @@
Specific version upgrades are described below. Please note that version upgrades are incremental.
If you are upgrading across multiple versions, make sure to follow the steps for each of them.
## Upgrading to Icinga DB Web v1.4
**Behavior Changes**
Modules that provide integrations for a host's or service's detail view now have unrestricted access to all custom
variables of said object. This is the case by accessing custom variables via the object's `customvars` property.
This was always meant to be the case, but due to an implementation oversight, the restrictions configured via
`icingadb/filter/objects`, `icingadb/filter/hosts` and `icingadb/filter/services` were applied and caused
unexpected or erroneous behavior. Though, in some cases this may not have been noticed or seen as a problem,
so when upgrading we recommend to review modules that provide such integrations and check if they rely on the
previous behavior. If so, accessing the `vars` property of an object should have the desired effect.
The following modules made by Icinga are safe and do not need an update to still work:
* Icinga Business Process Modeling
* Icinga Web Graphite Integration
Cases where this may not have been noticed are as follows:
* Restrictions only reference `host.*` columns and integrations only require access to host variables.
* Restrictions only reference `service.*` columns and integrations only require access to service variables.
Since these are very specific cases, we don't expect broad expectation of the previous behavior, but please review
your setup nonetheless if you use third party or custom modules that access custom variables this way.
## Upgrading to Icinga DB Web v1.3
**Requirements**

6
library/Icingadb/Model/Host.php
View file

@ -236,9 +236,9 @@ class Host extends Model
});
$defaults->add('customvars', function (self $subject) {
if (! $subject->customvar instanceof ResultSet) {
$this->applyRestrictions($subject->customvar);
}
// In contrast to customvar_flat, we cannot apply restrictions here as denylists and protections
// require the flattened values to work. To retrieve only customvars the user has access to, the
// `vars` property should be used instead.
$vars = [];
foreach ($subject->customvar as $customVar) {

6
library/Icingadb/Model/Service.php
View file

@ -228,9 +228,9 @@ class Service extends Model
});
$defaults->add('customvars', function (self $subject) {
if (! $subject->customvar instanceof ResultSet) {
$this->applyRestrictions($subject->customvar);
}
// In contrast to customvar_flat, we cannot apply restrictions here as denylists and protections
// require the flattened values to work. To retrieve only customvars the user has access to, the
// `vars` property should be used instead.
$vars = [];
foreach ($subject->customvar as $customVar) {