Documentation Center

Inheritance within the account

When you add and work with account resources, you need to know how location (the folder the resource is stored in) influences the way you and other users view and use this resource.

Inheritance = Access + Visibility

Users receive access to an account by being included in a group which:
  1. Is stored in a folder/location. The account folders are organized hierarchically.
  2. Has a role. A role is a set of permissions which give users the ability to manage account resources (view, add, edit, delete).Some roles have more permissions than others.
The position of an account resource in the account hierarchy influences its degree of visibility.
  • The higher the resource is positioned in the account hierarchy, the wider its visibility scope. In other words, if you want a resource to be visible and used by a greater number of users, you will save that resource higher in the hierarchy.
  • The account hierarchy enforces parent-child visibility and propagation.

For example, let 's say that you have several TMs. You would like TM1 to be used by everyone in your account, TM2 by all customers in your account, and TM3 only by a customer called Customer2.

Root
  • Customers
    • Customer1
    • Customer2

Where will you store your TMs?

Root (store TM1 here)
  • Customers (store TM2 here)
    • Customer1
    • Customer2 (store TM3 here)

What TMs can be used by everyone in the account?

TM1, because it is positioned the highest in the hierarchy.

What TMs can be used by Customer2?

TM2 and TM3

Are the TMs located in Customer1 visible to Customer2?

No, because Customer1 and Customer2 are brother folders.

In brief, account hierarchy ensures that:

  • Users can see and use the resources stored in their Home folder (current folder)
  • Users can see and use the resources stored in folders above the Home folder(parent or grandparent folders).
  • Users cannot see and cannot use the resources stored in brother folders or uncle folders.

Inheritance filtering

When you work with your account resources, you can quickly filter the resources you have visibility over. The UI filtering strategies are more restrictive than the API filtering strategies.

The UI

The available UI filtering strategies displayed in the wizards are:

  • Current folder and above
  • Current folder only

For example, let's say that you are creating a project and you would like to select a TM located in the Root folder. In the Translation Engine step of the wizard, select the Translation Memories section, and select the Current folder and above filter. The filter displays all the TMs located in the Root folder, as well as all the TMs located in your Home folder ( current folder).

The API

The API filtering strategies are not limited to parent-child inheritance. When using the API, you can also specify if you want to inherit from below or from anywhere in the system. This behavior is controlled by the " locationStrategy" parameter (Language Cloud API documentation).

Inheritance differences: projects vs. project resources

Until now we talked about account resources and assumed that all account resources are created equal. However, when it comes to inheritance, there is an important difference between the way projects and project resources( all the elements needed to create a project: users, project templates, workflows, linguistic resources and soon) are handled.

You can see the project resources in your:

  • Home folder( current folder)
  • Parent folder
  • Child folders
However, you can see the projects in your:
  • Home folder( current folder)
  • Child folders

Breaking inheritance by making a folder private

Setting a parent folder to private prevents users from child folders from seeing and using the parent resources. The folders in the initial account structure are public by default and cannot be made private. When you add further Customer folders and subfolders, they are public by default, but you can make them private to prevent upward propagation.
  • Root
    • Customers
      • Food Company
        • Dairy Department
        • Bread Department
          • GlutenProd
          • Gluten-freeProd

By default, all folders are public. You have several TMs with the following requirements:

  • TM_food must be visible to all Food Company users
  • TM_gluten must be visible to GlutenProd users
  • TM_bread must be visible to GlutenProd and Gluten- freeProd users

Where do you store your TMs?

  • Root
    • Customers
      • Food Company (store TM_food here)
        • Dairy Department
        • Bread Department (store TM_bread here)
          • GlutenProd (sotre TM_gluten here)
          • Gluten-freeProd

One day, you notice that TM_bread contains content that is suitable for Food Company users, but not for GlutenProd and Gluten-freeProd users. You do not want to move or delete the resource. How do you prevent GlutenProd and Gluten-freeProd users from seeing TM_bread? Tell you administrator to set the Bread Department folder as a private folder.

  • Root
    • Customers
      • Food Company (public)
        • Dairy Department (public)
        • Bread Department (*private)
          • GlutenProd (public)
          • Gluten-freeProd (public)

In brief, setting a folder as private exempts its resources from following the default upwards access propagation rules:

  • If a folder is public, the resources (project resources, users and groups) from this folder are visible to the users which have access in its child folders (via groups).
  • If a folder is private, the resources (project resources, users and groups) from this folder are not visible to the users in its child folders. Access to resources is governed by the location of the groups a user belongs to. Make sure users are not included in a group located in the parent folder (or above) of a private folder.