This was easy because only README.md and doc/01-About.md were redacted manually, everything else via:
git ls-files -z |xargs -0 perl -pi -e 's/Icinga GmbH \| GPLv2/Icinga GmbH | GPLv2+/'
This is legal because we have only merged PRs with label:cla/signed or made by Icinga staff:
https://github.com/Icinga/icingadb-web/pulls?page=1&q=is%3Apr+is%3Aclosed+-label%3Acla%2Fsigned+-author%3Anilmerg
This has no risk for us in people distributing their own version under GPLv3 only.
After all, we won't take their patches anyway, unless they sign our CLA.
This is the cleanest solution for having e.g. these in one address space:
* Icinga Web, GPLv2+
* K8s Web, AGPLv3
* Thirdparty, some LGPLv3 and Apache-2.0
Apropos, K8s Web is even v3-licensed on purpose, to have a stronger protection against cloud ops.
* Auth: Add method `assertColumnRestrictions`
* ObjectSuggestions: Do not suggest protected variables
`assertColumnRestrictions` does not allow to use them
anymore, hence we should not suggest them in searches
as well to not to let the user run into an error by
accepting a suggestion. Though, when fetching values
as well, we still have to obfuscate, otherwise protected
vars won't show up in details anymore.
* Introduce Icinga\Module\Icingadb\Common\Model
Must be used as base for all models, to ensure
column restrictions are asserted on filters.
* Utilize `Icinga\Module\Icingadb\Common\Model` where applicable
* Lists show it in their visual and title area
* The tatical view includes a slice for them
* State badges (list footers, host-/servicegroups) also show a badge
Previously:
* Base columns were identified as relation columns
* Base columns were not enriched (had no labels)
* Hostgroup columns were invalid in the servicegroupsummary and vice versa
Previously, all name columns in the UNION queries yield NULL except for
the Hostgroup or Servicegroup query. In PostgreSQL, this leads to
separate result sets because all SELECT columns must appear in the GROUP
BY clause, which also includes name columns.
Type resolution for UNION (CASE and related constructs) in PostgreSQL
works by taking the UNIONed queries 2 at a time, i.e. the first TWO
queries are resolved, then it takes the result and resolves it with the
next query and so on.
Previously, when using Hostgroup as the first query and Host (or
Service) as the next query, PostgreSQL encounters two NULL values for
the host_handled (or service_handled) column, resulting in the type
text. This leads to the following error:
UNION types text and boolenum cannot be matched.
Now Hostgroup is the last query that ensures there are not two
consecutive NULL values for host_handled (or service_handled).
NOTE: BREAKING: This change breaks other code that extracts the "base
query" which depends on Hostgroup or Servicegroup being the first query
in the getUnions() array, which has yet to be fixed. In preparation for
a possible fix that could simply use the last query instead of the
first, the Servicegroup query has also been moved to the end.
