What Is a Namespace?

When you reference or deploy an artifact, such as a task script file, you must include this information:

• namespace
• orgSlug
• version

The combination of the namespace, orgSlug, and version indicates where the artifact is stored in S3, and who has permission to access it. This same combination of a namespace, orgSlug, and version is also used to identify and organize other artifacts, such as IDS schemas or other files.

What is a Namespace?

A namespace defines a realm where only those who have the appropriate permissions can use the artifacts in that realm. There are three main categories of namespace:

• common
• client
• private

common Namespace

The common namespace is used for artifacts that are published by TetraScience. Members of all organizations have read access to the artifacts in the common namespace.

client Namespace

The client namespace indicates the artifact was published by TetraScience for a client. The client namespace must be appended with one or more orgSlugs, which indicate which organization and department(s) have access to artifacts. The nomenclature is: ‘client-org1’ where ‘org1’ is the organizational slug for an organization.

For example, if your organization’s slug is named ‘tetra’, the namespace would be ‘client-tetra’. You can append one or more extensions (such as, departments): 'client-org1-ext1-extn'. (For example: ‘client-tetra-dev-uat’)

To view (read) the artifact, members must have permission to access all of the orgSlugs that are appended. For example, artifacts in the ‘client-tetra-dev’ namespace can be read by those who are in tetra, and are part of the dev department. It cannot be accessed by members of 'tetra' who are not also members of 'dev'.

private Namespace

The private namespace indicates the artifact was published by the client. An example of this is a client publishing a Self-Service Pipeline. The private namespace, like the client namespace, must appended with one or more orgSlugs, which indicate which organization has access to artifacts. The nomenclature is ‘private-org1’, where ‘org1’ is the orgSlug for an organization.

For example, if your organization’s slug is named ‘pharmaco’, the namespace would be ‘private-pharmaco’. You can append an orgSlug, and one or more extensions (such as, departments): 'private-org1-ext1-extn'. (For example: ‘private-pharmaco-rd-analysis’).

To read (view) and write to (modify) the artifact, members must have permission to access all of the orgSlugs that are appended. For example, ‘private-pharmaco-rd’ can be read and written to by those who are in pharmaco (PharmaCo) in the rd (R&D) department. It cannot be accessed by members of 'pharmaco' who are not also members of rd.

Permissions Summary Table

The following table summarizes the previously described access types:

The orgSlug column indicates whether a user of the software is part of the parent organization (org1), and whether they are part of one or more departments in the organization (ext1, ext2). Org0 represents a user who is not part of the organization.

The namespaces columns show examples of different namespaces: common, client, or private.

The matrix indicates whether the user has:

• N/A - no access, which means they cannot view or modify the artifact
• R - read access, which means they can view the artifact
• R/W - read/write access, which means they can view and modify the artifact

For example: A scientist, who is a TDP user, works at a parent organization named pharmaco (org1) in the R&D department (ext1).

The scientist can:

• View artifacts in the common (org0), client-pharmaco (client-org1), and client-pharmaco-rd (client-org1-ext1) namespaces
• View and modify artifacts that are in the private-pharmaco (private-org1) and private-pharmaco-rd (private-org1-ext1) namespaces

The scientist cannot:

• View or modify artifacts that are in client-pharmaco-rd-analysis (client-org1-ext1-ext2) or private-pharmaco-rd-analysis (private-org1-ext1-ext2) namespaces