How Content Level Security and Dynamic Release Management interact

Default settings for Versions

The default setting of a new Version is Read-write access for the group Everyone.

When you create a new Version, the default settings are applied.

When you clone a Version, the Version's security settings are also cloned.

Access to shared content with mixed security settings

If content is shared across multiple branches with different security settings, the most permissive settings prevail. In other words, if a user has access to any branch that contains the content, the user has access to that content.

Content is shared when the same instance of an object is reused across multiple branches. For example, if the same instance of an object is reused across branch 1, branch 2, and branch 3 and a user has access only to branch 3, the user has access to the object.

Therefore, this does not apply to maps because the same instance of a map cannot be reused across branches. Maps always have a separate instance per branch.

If a topic, image, or resource is shared between a branch that the user has write access to and a branch that is hidden to the user, IXIA CCMS always forks the object to create separate instances in the writable branch and the hidden branch. This is necessary because without forking, the user would also make edits within the hidden branch, which is not permitted—this would violate the security settings on that branch for that user. To prevent the user from making edits in the hidden branch, the fork is required. While this seems like a contradiction to the "most permissive settings prevail" principle, it is not. Because the user does have write access to one of the object's branches, they have access, so the most permissive settings do prevail. They can edit the object, but only in the writable branch.

Visibility of content across parent-child Libraries

When users have visibility into a Library, they always have visibility into any child Libraries. This ensures that security settings do not create visibility gaps or broken links.

It's not possible to accidentally give access to a parent Library while hiding content in a child Library. If a group has Read-write access or Read-only access to a parent Library, IXIA CCMS prevents you from giving the group no access to any child Libraries. At minimum, the group must have Read-only access to the child Libraries.

The restrictions do not guarantee that users have the same level access to child libraries. Users can have Read-write access to a parent Library and Read-only access to a child Library. The restriction applies only to visibility, not the ability to edit.

For example, assume you have Library A and its child Library named Library B. If a group of users have Read-write access to the content in Library A, when you set security on the libraries, the system ensures that the users have at least Read-only access to Library B.