Release Notes / Version 10.2107
Table Of ContentsThe Content Management Server maintains stable and universally unique identifiers (UUIDs) as specified in RFC 4122 for users and groups. Existing and newly created users and groups get UUIDs in addition to existing numeric IDs. UUIDs are not meant to replace existing IDs, and IDs can be used for all purposes as before. Note, that UUIDs are currently only available on the Content Management Server , and not on live servers.
Upgrade:
The Content Server automatically adds new database table columns for UUIDs when started. This affects both management and live servers.
Note, that it is not possible to start a Content Server of a previous release on the database after the new Content Server has adapted the database tables. You should always make a backup of the Content Server database before upgrading. This is even more important for this change.
The Content Server automatically generates UUIDs for existing and newly created builtin users and groups. Predefined well-known users ("admin", "feeder", "studio", "watchdog", "webserver", "publisher", "workflow", "importer", "replicator") and groups ("administratoren", "system", "system-write", "approver", "chief editor", "editor", "importer", "publisher", "composer-role", "approver-role", "publisher-role") receive fixed UUIDs, that will be the same on all systems. For all other builtin users, the Content Server generates random UUIDs that will differ between installations.
External user provider implementations can import UUIDs from an external system, so that logically identical users and groups can have the same UUIDs on different CMS installations. To this end, the
ActiveDirectoryUserProvider
and
SimpleActiveDirectoryUserProvider
use Active Directory's objectGUID attribute as UUIDs for the CMS. Custom user provider implementations can be adapted to assign specific UUIDs to their users and groups as well. By default, the
Content Server
generates random UUIDs for members of custom user providers, so that there's no requirement to adapt them.
Unified API:
In the Unified API , the following methods have been added for UUID support:
Member#getUuid()
UserRepository#getMember(UUID)
UserRepository#getUser(UUID)
UserRepository#getGroup(UUID)
Furthermore, the existing methods
#getMember(String)
,
#getUser(String)
, and
#getGroup(String)
of interface
UserRepository
can now also be called with a UUID's string representation to lookup a user or group by its UUID.
If the
Unified API
is connected to a live server or to a server of a previous release, then methods that would return a
UUID
will return
null
instead.
The Unified API Developer Manual mentions UUIDs in the new section "The User Repository | UUIDs".
UserProvider API:
The API to implement custom user providers has been extended with new methods for UUID support:
UserProvider#getUser(UUID, boolean)
UserProvider#getGroup(UUID, boolean)
LdapUserProvider#idToUuid(String, Attributes)
LdapUserProvider#uuidToId(UUID)
LdapObject#getUuid()
cm dump:
Extended first line of console output for user and group dump by pattern
, uuid: <uuid>
(just in case you used this line for parsing in automated processes).You may now pass UUIDs as input arguments not only for contents, but also for users and groups. Either directly or via option
-U
.
(CMS-16917)