Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://help.tableau.com/current/server-linux/en-us/permissions_projects.htm below:

Manage Permissions with Projects - Tableau

Projects can simplify permission management with features such as nested projects, project visibility, non-admin project leaders, and locking permissions.

Tip: How permissions are set at the project level is 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.

Projects are containers used to organize 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 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. (Project leaders can't change project ownership, only content ownership). Projects can be owned by users with a site role of Explorer (can publish), Creator, or administrator. Project ownership can be changed even if a project is locked.

Deleting: Most 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 Tableau 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.

External assets are handled differently. They don’t have to be in a project. External assets aren’t deleted if their project is deleted and continue to appear in External Assets. See External assets that aren’t in projects for more information.

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

Default: The project named "Default" is a special project. When other top-level projects are created, they use the Default project as a template, and copy all their permissions rules from it (but not the Asset permissions setting). The Default project can’t be deleted, moved, or renamed, but its description can be changed. It has no owner by default, but one can be assigned.

External Assets Default Project: In Tableau Cloud and Tableau Server 2023.1 and later, if you have a Data Management license with Catalog enabled, the project named "External Assets Default Project" appears when Catalog needs to move new or existing external assets to it. Catalog puts new external assets and external assets from deleted projects in the External Assets Default Project. The project has no permissions rules by default, so server administrators and site administrators are the only users who can see it unless permissions are added. It can’t be deleted, moved, or renamed, but its description can be changed. It has no owner by default, but one can be assigned.

Project leaders are users who have administrator-like access for a specific project or project hierarchy.

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 needs 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.

After a permission rule establishes a project leader, the templates and capabilities can't be edited because all capabilities are allowed for project leaders. If a project leader is established on a project that contains nested projects, they 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 but select Remove as Project Leader from the action menu. After a group or user has been removed as project leader, that permission rule has all capabilities set to Unspecified. This may mean their access to and capabilities for that project is removed if there’s no other permission rule giving them permissions to the content. To keep their access to the project and its content, they need to have capabilities set like any other group or user.

Note: Project leaders can refresh extracts in their projects in most circumstances. They can't refresh extracts if they're only the project leader of a nested project (instead of a top-level project) and the top-level project is locked (including nested projects).

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 Asset permissions setting. This setting can be configured in two ways, either Locked (recommended) or Customizable. 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 Asset permissions is Locked (including nested projects), permission rules set at the project level are enforced for all assets in the project and all nested projects.
• When Asset permissions is Locked (not including nested projects), permission rules set at the project level are enforced for assets in the project. Nested projects can be configured independently with their own permission rules and set as locked or customizable.
• When Asset permissions is Customizable, permission rules set at the project level are applied to all assets in the project by default. However, permission rules can be modified for individual assets during or after publishing.

Note: Whether permission rules are locked or customizable, the permissions on content are always applied. Locked and customizable refer only to how project-level permissions are inherited by content in the project and who can change them. Even in a project with customizable 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 assets.
• 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 customizable 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.

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

To configure Asset 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. Next to Asset permissions in the upper left, click the Edit link and select the desired option in the Asset 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) piece of content in a customizable project, which won’t show anything, or (c) 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.

When the Asset permissions 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.

Doesn’t modify existing permission rules.

Any nested projects become customizable.

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

Any nested projects become customizable.

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

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

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

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

Any nested projects retain their permission rules and remain customizable.

When Tableau content or external assets are moved between projects with different permission settings, Asset permissions settings determine the logic of how permissions are applied.

• Moving assets into a locked project overrides the existing permission rules and enforce the destination’s permissions.
• Moving assets into a customizable project maintains the existing permission rules on the asset.

Note: Prior to Tableau Server 2022.3 and Tableau Cloud June 2022, external assets couldn’t be in projects, and permissions on tables were managed through the Table permissions setting of the parent database. Beginning with Tableau Server 2022.3 and Tableau Cloud June 2022, external assets can be in projects. If a database or a table is moved into a project, older settings to control table permissions through the database are ignored, and the database or table permissions follow the logic of other assets.

When a project is moved into another project, the permissions settings on the item being moved are maintained unless the destination project is scoped to include nested projects. (Project permissions in this case mean the View and Publish capabilities for the project itself.)

• If the destination project is set to locked (including nested projects), the permissions for the project being moved and its content are overwritten.
• If the destination project is set to locked (not including nested projects), the permissions for the project being moved aren’t overwritten. Whether the moved project is locked or customizable is preserved from its original setting.
• If the destination project is set to customizable, the permissions for the project being moved aren’t overwritten but they’re 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.

Moving nested projects inside locked (including nested projects) environments can be tricky. A project can be moved into situation that prevents the user from moving it out again.

If a nested project is owned by a different user than the managing project, and the managing project is set to locked (including nested projects), a nested project can wind up unable to be moved by anyone except an admin.

For example, consider a locked (including nested projects) top-level project owned by userA, and two nested projects owned by userB. If userB moves one nested project inside the other, they aren't then able to move it back out—and neither is userA.

• UserB can't move Nested project2 because they don't have rights to move rights on Top-level Project as a destination.
• UserA can't move Nested project2 because they don't have move rights on it.
• A project leader on Top-level Project can't move it even though project leader trickles down to nested projects.
• Only an admin can move Nested project2 in this setup.

Unlike projects, which contain content, a collection can be thought of as a list of links to content. Project permissions can be inherited by the content in the project, but permissions for a collection have no effect on the content added to the collection. This means that different users might see different numbers of items in a collection, depending on which items they have permission to view. To make sure that users can see all items in a collection, adjust the permissions for those items individually.

Permissions for a collection can be changed either by using the permissions dialog or by granting access upon sharing a collection, if you’re an administrator or the collection owner. For more information, see Manage Collection Permissions.

When a collection is created, it’s private by default. A private collection appears on the owner’s My Collections page, but it doesn't appear in the list of all collections on a site. Private collections are simply collections with no permission rules added. Unlike other types of content, collections don't have the “All Users” group added by default. When you add permission rules to a collection, it’s no longer flagged as private. To return a collection to a private state, remove the permission rules.

Private collections can be viewed by the collection owner as well as by administrators, whose site role gives them effective permissions to view all collections.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4