Release Notes / Version 12.2412.0
Table Of ContentsA feature previously known as a kind of “fallback” has been matured. This fallback was known to take over, when the “site manager groups” field of a given site was empty.
Due to the nature of this change, this “fallback” is now called “alternative”, as you may apply different strategies for different use-cases on application configuration level.
Without diving into the past, here is, what is possible now (find more details in Blueprint Developer Manual):
The Default Behavior
The default behavior has not changed much – the only change is, that it now aligns better with the documented approach:
The only entry for alternative groups is, as before, the group with ID 0 (zero), named
administratoren(this is a hard-wired name that cannot be changed).If the site manager groups field is empty, the alternative groups are used instead.
Now, also, if all groups within the site manager groups field are invalid (there is a validator to signal this broken state), also, the alternative groups will be applied. As stated, this aligns with the documented behavior.
Possible Adaptation: External User Repositories
For purely externally managed users, the default approach is flawed: There was no option, to also provide alternative groups from this external repository.
This is possible now, as you may, for example, configure:
sitemodel.siteManagerGroupAlternatives=administrators@example.org,coremedia:///cap/group/0
Possible Adaptation: Always Consider Administrators
As another adaptation, that ships with this release, you may also change the strategy, when these alternatives are considered. For example, if you want your configured alternative groups to be always taken into account (like, to possibly take over for absent editors), you may do so by changing the strategy:
sitemodel.siteManagerGroupAlternativesStrategy=ALWAYS
Upgrade Notes
While the behavior has not changed much from before using the default Blueprint configuration (despite fixing to also consider alternative groups, when given ones are all invalid), there have been some compatible changes on API layer:
A new enumeration
SiteModel.SiteManagerGroupAlternativesStrategyhas been introduced.The
SiteModelinterface provides new methods (backed by default implementation that are aligned with the previous behavior):getSiteManagerGroupAlternatives() : List<String>getSiteManagerGroupAlternativesStrategy() : SiteModel.SiteManagerGroupAlternativesStrategy
The latter may require, at least on unit test level, to possibly adapt
your mocks of SiteModel. It should require no
adaptation in your existing production code.
The upgrade involves these applications, that should be updated for the feature to work to its full extend:
Studio-Server, required to be able to actually start the localization workflows;
Localization Workflows using
GetSiteManagerGroupAction(like the Translation Workflow, that ships as part of the CoreMedia Blueprint). While the API of the action did not change, it is important to also update these artifacts, as otherwise your configured alternative groups may not be able to proceed handling started localization workflows.
(CMS-25668)
