Manage Sites in a Shared Repository

Many companies have an extensive number of sites that are created and managed by various business teams. Sharing the same repository for all sites can ease overhead and streamline site management.

Sites can be public, such as a marketing site, internal, such as a team site, or secure so that only specific users, internal and external, can see them. In all cases, the business team managing the site typically does not want people outside the team to edit or even see content used on the site before it is published. Creating a repository for each site in order to segregate each site's content is not a tenable solution, as that would cause an overhead of managing potentially thousands of repositories.

Instead, Oracle Content Management can apply granular permissions on assets to separate site content based on category, allowing sites to share one repository while controlling access to specific sites and site assets. Separate repositories would then be used only if access to confidential content is highly restricted, such as financial documents or information on mergers and aquisitions.

To manage access to a shared repository, a site developer creates or edits a template to require the use of a site security taxonomy (SST). They then either create a new taxonomy, or edit the general properties of an existing taxonomy, and specifiy it for use with site security management. Once a taxonomy is done, it must be promoted and added to the repository being used by the site.

Taxonomy general properties


SST templates automatically create categories in a taxonomy during site creation, and so taxonomies used with site security management must be promoted before they can be used when creating sites. If a draft of the taxonomy exists when an SST template is used to create a site, even if a version of the taxonomy has been promoted, then site creation fails.

When a member of the team creates a site using an SST template (denoted by a badge icon SST badge in the template corner), they are required to select a parent category for site content, and name the site. When the site is created, a new site category is automatically inserted into the taxonomy as a child of the parent category, using the site name. For example:

  • <selected_parent_category>

    • <site-name>_site_category

All site assets are categorized with the new site category. This allows assets for each site to use a single repository while being discrete.

In addition, two new groups also named using the site name are created and added to the repository:

  • <site-name>_viewer

  • <site-name>_contributor


Do not remove site assets from the site category. Doing so removes access to site assets from the site content viewer and contributor groups when those assets are also catogorized outside of the secure site taxonomy.

A person is automatically assigned to a group when an SST site is shared with them, based on the role they are given. A person given the view or downloader role is assigned to the site content viewer group. A person given the manager or contributor role is assigned to the site content contributor group.

By default, those with the viewer role can see all asset types in the site category of the repository. Those with the contributor role can categorize, create, edit, and delete all asset types in the site category. These default permissions can be edited to refine access at a more granular level if needed, controlling who has access to which sites and content. For more information, see Granular Permissions.