Skip to main content

Documentation

Planning collection & permissions for collections
Plan the collections

First, plan the collections structure for your organization. Determine what collections you need. For example, you can follow the following paradigm.

Table 1. Types of collections

Type

Usage

Source collections

For each collector output.

Domain collections

Organizational categories that map to the domains of your business or organization. Domain collections are likely curated by data stewards and can include subdomain collections (i.e. hierarchical collections)

Glossary collections

For business glossary in the organization.



Plan the permissions for collections

Decide if you want to set access permissions on collections to govern who can view the content of the collections, edit them, or give others access. Setting granular permissions on collections help you achieve the following business needs:

  1. You want to put people in charge of a smaller footprint of the catalog, and have a good reason why those same people should not have administrative permissions for the entire catalog.

  2. You want to split up roles between different groups for things like running collectors vs curating a glossary.

  3. You want to make sure that people are only receiving notifications for things they are responsible for and want to direct things like suggestion approvals to a specific audience.

  4. You want to hide part of the catalog from certain groups. Note that hiding certain parts of the catalog from members will impact their experience of the catalog and is not a recommended way of setting up the catalog. For example, it may happen that members will not be able to see all related resources for a catalog resource. It will also impact lineage as members will not be able to see lineage if they do not have view access to the resources that are part of lineage.

    Important

    Permissions for collections and datasets and projects are managed separately. Datasets and Projects cannot be added to collections at this time and hence their permissions are managed differently.

Overview of how access control works

Levels of access

  1. You can grant permissions for metadata resources at two levels:

    1. Catalog level - For the entire metadata catalog: Permissions can be granted to organization groups.

    2. Collection level - For a specific collection within the catalog: Permissions can be granted to individual organization members or to organization groups.

  2. Supported access levels for metadata catalog resources.

    collection_permissions.png
    Table 2. Permissions overview

    Permission

    What the member can do

    Not set

    Members cannot search for or navigate to the resource. The resource does not exist for the member.

    NOTE: If members have access to the collection through organization level or parent collection level settings, they will be able to access the collection.

    View

    Members can search for and navigate to the resource.

    Edit

    View permissions + Member can update metadata, approve suggested changes, and delete the resource.

    Manage

    Edit permissions + Member can manage permissions for the resource.



When resources belong to multiple collections:

  1. If a resource belongs to two collections and you have Edit access on one collection and View access on another, you will get the highest level of access, that is, you will be able to edit the resource.

    multiple_collection01.png
  2. Likewise, if at the organization level you are granted Edit access to all catalog resources and given View access to a specific collection, you will be able to edit the collection and the resources in it.

    multiple_collection02_.png
  3. If at the organization level you are NOT granted any access to catalog resources and given View access to a specific collection, you will be able to view the collection and the resources in it.

    multiple_collection03a.png
  4. Also note that when you have access to tables through a collection, you automatically get access to the columns for those tables, even if the columns are not part of the same collection.

    multiple_collection_table_colm.png

When you have collection hierarchy setup:

Collection hierarchy is a feature enabled by the data.world team on request for select customers. This feature allows you to create collections within collections to better organization your resources in small logical groups under a larger umbrella.

  1. If you have View access to the parent collection and no access to the child collection, you will be able to see both the parent collection and the child collection and resources in both the collections.

  2. However, if you do not have access to the parent collection, but can View the child collection in it, you will be able to view only the child collection and the resources in it. You will not have access to the parent collection or any resources in that parent collection.

    On the child collection page, you will see that the collection has a parent, but that parent will not be something you can view. Clicking on the parent from the child collection will display a page not found error (a 404 page) with a notice that the user may not have access to the resource they are trying to visit.

  3. If a collection has two child collections, and you have View access to the parent collection and Edit access to only one child collection, you will be able to view the parent collection and both child collections, but you will be able to only edit the collections (and the resources in it) for which you have Edit access.

    nested_collection.png

Watch this video for an overview of how access control works: