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