There was a problem with software update checks configurations stored in
config.yaml for which the providing plugin was then removed, since those
check definitions then lacked their default values to be merged on whatever
was stored in config.yaml, causing incomplete check configurations as a
consequence over which the plugin tripped.
This patch fixes that in that it tracks which check config keys are provided
by plugins and only returns those as the active check configurations that
belong to plugins that are still in the system.
TODO: This is only half of the solution. Check configurations of plugins
that are being uninstalled should be removed from the config if the
user decides to remove any settings by the plugin too. We need some
adjustments in the lifecycle tracking in order to make this possible
however, so for now this must suffice to at least prevent any errors from
occuring when incomplete configs are encountered.
(cherry picked from commit 8af8b8f)
There was a problem with software update checks configurations stored in
config.yaml for which the providing plugin was then removed, since those
check definitions then lacked their default values to be merged on whatever
was stored in config.yaml, causing incomplete check configurations as a
consequence over which the plugin tripped.
This patch fixes that in that it tracks which check config keys are provided
by plugins and only returns those as the active check configurations that
belong to plugins that are still in the system.
TODO: This is only half of the solution. Check configurations of plugins
that are being uninstalled should be removed from the config if the
user decides to remove any settings by the plugin too. We need some
adjustments in the lifecycle tracking in order to make this possible
however, so for now this must suffice to at least prevent any errors from
occuring when incomplete configs are encountered.
Caused a KeyError so far, update definitions that are broken like that
will now just be ignored instead.
Closes#1057
(cherry picked from commit 2efc5c4)
Sessions could get duplicated, wrongly saved etc. The reason was not
persisting the actual user object to the internal session map (but the
LocalProxy instead). That could lead to multiple sessions being
created for one login, or the session user being set to an
anonymous user, or various other odd effects depending on timing.
(cherry picked from commit 8aeac51)
Sessions could get duplicated, wrongly saved etc. The reason was not
persisting the actual user object to the internal session map (but the
LocalProxy instead). That could lead to multiple sessions being
created for one login, or the session user being set to an
anonymous user, or various other odd effects depending on timing.
Moving from the button to the username field probably makes even more
sense and while we are at it we can also extract the element access into
proper variables.
