1 Mar
2021
1 Mar
'21
8:02 a.m.
Branch: refs/heads/2.0.0
Home: https://github.com/tribe29/checkmk
Commit: 58ae7e12a3a7c83df76a96d5b3efbcc789d1e8fb
https://github.com/tribe29/checkmk/commit/58ae7e12a3a7c83df76a96d5b3efbcc78…
Author: Lars Michelsen <lm(a)tribe29.com>
Date: 2021-03-01 (Mon, 01 Mar 2021)
Changed paths:
M cmk/gui/config.py
M cmk/gui/plugins/config/base.py
M cmk/gui/valuespec.py
M cmk/gui/watolib/__init__.py
M cmk/gui/watolib/activate_changes.py
M cmk/gui/watolib/global_settings.py
M cmk/gui/watolib/hosts_and_folders.py
M cmk/gui/watolib/utils.py
Log Message:
-----------
Fix exception "unknown site ID" on remote sites
This exception could occur when opening the "host properties" page on
remote sites. This issue only affects users that enable WATO (Setup) on
a distributed wato remote site.
If neither the host nor its parent folders has been assigned a site_id,
it falls back to the default site ID which is normally the local site.
This works for single sites and central sites in distributed setups, but
not for remote sites in distributed setups.
Previously the site_id was set to False internally (which was also
visible to the user) because the remote site did not know the site ID of
the central site. This is how it worked in 1.6 and until now partially
in the 2.0 code.
Sadly this was not working completely. The type hints were already
showing that this had to be fixed. Otherwise we would have to change
many more places to deal with the Union[Literal[False], SiteId] type of
the site_id which is obviously just a bad hack. It seemed clear that the
total cleanup of the type is the only valid way to go, even this short
before the release.
The first thing we needed to solve this is to make the remote site aware
of the site_id of the central site. This is now done by writing the
wato_distributed_central_site GUI config setting for the remote sites.
Once this is known, the site_id attribute can now fall back to the ID
of the central site instead of False.
Change-Id: I447d1e18629ac593a21059b5934cb679e30cc2c6