Manage Permissions with Projects

Using projects can simplify permission management through features such as nested project hierarchies, hiding projects from certain users or groups, authorising project leaders and locking permissions.

Tip: How permissions are set at the project level is very important, especially for the Default project. When a new top-level project is created it inherits its default permission rules (for all content types) from the Default project. When a new project is created nested inside another project, the child project inherits its default permission rules from the parent project.

Project administration

Projects are containers used to organise and manage access to content. By giving non-administrators privileges to manage projects, certain content administration tasks can be handled at the project level.

Project Leaders: Projects can have project leaders, users who have been set as a project leader. This setting automatically grants a user their maximum capabilities – depending on their site role – for that project and all content in that project. Project leaders with site role of Explorer (can publish) and above will therefore have all capabilities. Project leaders are essentially local admins for the project without access to site or server settings.

Hierarchy: Only administrators can create top-level projects. Project owners and project leaders can create nested projects inside their projects. Project owners and leaders have full administrative access to the project and its content, as well as any nested projects it contains. In a hierarchy, project leaders are implicitly given project leader access to all child content. To remove project leader access, you must do so at the level in the hierarchy where the role was explicitly assigned.

Ownership: A project can have multiple project leaders, but each project has exactly one owner. By default, a project is owned by the user who created it. A project’s owner can be changed (by the existing owner or an administrator, but not a project leader) to any user with a site role of Explorer (can publish) or Creator, or an administrator site role. Project ownership can be changed regardless of whether the project permissions are locked. Note that this refers to project ownership. Content ownership can be changed by project owners, project leaders and administrators.

Deleting: Content can only exist inside a project. Only administrators can create and delete top-level projects, but project leaders can create or delete nested projects. Deleting projects also deletes all the content and nested projects they contain. To delete a project without losing its content, move the content to another project first. Deleting projects can’t be undone.

For a deeper dive into project administration, see Use Projects to Manage Content Access and Add Projects and Move Content Into Them.

Set a project leader

Project leaders are users who have administrator-like access for a specific project or project hierarchy. Prior to 2020.1, Project Leader was a capability that could be set to allowed, denied or unspecified like any other capability. Starting in 2020.1, project leaders are now assigned through the action menu and function as a setting rather than a capability.

To assign project leader status to a group or user

  1. Open the permission dialog for the appropriate project.
  2. Select an existing permission rule, or click + Add Group/User Rule and chose the desired group or user.
  3. Open the action menu (...) for that permission rule and select Set Project Leader....

Note: If the action menu includes an option for Enable “Set Project Leader”, this will need to be selected before the group or user can be set as a project leader. This option only appears when that group or user was denied the Project Leader capability (prior to 2020.1). That denied capability needs to be removed before they can be set as a project leader.

Once a permission rule has been used to establish a group or user as a project leader, the templates and capabilities are no longer editable because all capabilities are allowed for project leaders. If a project leader is established on a project that contains nested projects, they will have inherited project leader status on all nested projects and their content.

Project leader status is always applied downward through the entire project hierarchy and can only be removed from the level where it was set. To remove project leader status, follow the same steps as above but select Remove as Project Leader from the action menu. Once a group or user has been removed as project leader, that permission rule will have all capabilities set to Unspecified. This may mean their access to and capabilities for that project will be removed if there is no other permission rule giving them permissions to the content. To keep their access to the project and its content, they will need to have capabilities set like any other group or user.

Lock content permissions

Permission rules set at the project level act as a default for content saved in that project and any nested projects it contains. Whether those project-level default rules are enforced or only preliminary depends on the content permission setting. This setting can be configured in two ways, either Locked (recommended) or Customisable. Locking a project removes the ability for content owners to modify the permission rules on their content. Locking permissions can be applied to nested projects or just to the parent project itself.

  • When the content permissions are locked (including nested projects), permission rules set at the project level are enforced for all content in the project and all nested projects. (This was the default behaviour for locking projects prior to 2020.1)
  • When the content permissions are locked (not including nested projects), permission rules set at the project level are enforced for content in the project, but nested projects can be configured independently with their own permission rules and as locked or customisable. (This is new behaviour for locking projects as of 2020.1)
  • When the content permissions are customisable, permission rules set at the project level are applied to all content in the project by default. However, permission rules can be modified for individual pieces of content during or after publishing. (This was called Managed by the owner prior to 2020.1)

Note: Whether permission rules are locked or customisable, the permissions on content are always applied. Locked and customisable refer only to how project-level permissions are inherited by content in the project and who can change them. Even in a project with customisable permissions, only specific users can modify permissions (content or project owner, project leader, admins or those with the Set Permission capability).

In a locked project:

  • The project permission rules per content type are applied to all content.
  • Only administrators, project owners and project leaders can modify permissions.
  • Content owners lose the Set Permission capability but retain all other capabilities on their content.
  • Permissions are predictable for all content in the project.

In a customisable project:

  • The project permission rules are applied by default when content is published into the project or nested projects are created, but permissions can be modified during publication or after the content is created.
  • Any user with the Set Permissions capability can modify permission rules for that content.
  • Content owners have all capabilities on their content.
  • Permissions can be different across content in the project.

Set content permissions (lock a project)

New top-level projects inherit all initial permission rules from the Default project but not the content permissions setting, which is set to Customisable. This can be changed to Locked if desired.

To configure the Content Permissions:

  1. You must be logged into the site as an administrator, project owner, or project leader
  2. Open the permissions dialog for a project
  3. Click the Content Permissions Edit link in the upper left and select the desired option in the Content Permissions dialog

Note: If the upper left corner doesn’t show an Edit link in step 3 above, you may be on the permissions dialog for (a) a nested project or a piece of content in a locked project, in which case the link should bring you to the managing project, (b) a piece of content in a customisable project, which won’t show anything or (c) a view, which will indicate how the view permissions are tied to the workbook. For more information on the interplay of permissions for views and workbooks, see Show or Hide Sheet Tabs.

Change content permissions

When the content permission setting for a project is changed, the outcome depends on the new setting. Changes to permission rules in a locked hierarchy must be done at the level of the managing project.

Changing from Changing to Outcome
Locked (including nested projects) Locked

Doesn’t modify existing permission rules.

Any nested projects become customisable.

Customisable

Doesn’t modify existing permission rules, though they become customisable.

Any nested projects become customisable.

Locked Locked (including nested projects)

Overwrites existing custom permission rules for all nested projects and their content. This can’t be undone.

Customisable

Doesn’t modify existing permission rules, though they become customisable.

Any nested projects retain their content permission settings and permission rules.

Customisable Locked (including nested projects) Overwrites existing custom permission rules for content in the project, as well as all nested projects and their content. This can’t be undone.
Locked

Overwrites existing custom permission rules for content in the project. This can’t be undone.

Any nested projects retain their permission rules and remain customisable.

Move projects and content

When a project is moved into another project, the permissions settings on the project being moved are maintained unless the destination project is scoped to include nested projects.

  • If the destination project is set to locked (including nested projects), the permissions for the project being moved are overwritten.
  • If the destination project is set to locked (not including nested projects), the permissions for the project being moved are not overwritten. Whether or not the moved project is locked or customisable is preserved from its original setting.
  • If the destination project is set to customisable, the permissions for the project being moved are not overwritten but they are now editable.
    • If the project being moved was previously nested under a parent that was locked (including nested projects), when moved, the project takes on the setting of locked (including nested projects) and becomes the managing project for any projects it contains. Note: This is the same outcome if a project is moved to become a top-level project.
Thanks for your feedback!