Marketplace stores can be either local to your Foundry enrollment or remote. A local Marketplace store can be found in either a Project or folder and will inherit the permissions of the Project or folder in which it is situated. Remote stores are created on one Foundry enrollment and then made available on other enrollments. Permissions for remote stores are configured in Control Panel.
To view a local Marketplace store in either DevOps or Marketplace, you need to have the marketplace:read-local-marketplace operation, which is normally granted with the Viewer role. Viewer permissions for a remote store are configured in Control Panel.
To install products from either a local or remote store, you must be able to view the store and have the marketplace:install-from-local-marketplace operation, which is normally granted with the Viewer role.
For every resource selected as an input to this installation, you must have the marketplace:use-resource-as-input operation, which is also normally granted with the Viewer role.
Additionally, the locations where you can install, typically the Space and Ontology, require the marketplace:install-in operation, which is usually granted with the Editor role.
With each installation, Marketplace will either create a new Project in the selected Space or install into an existing Project. To do this, you will need the marketplace:install-in operation on the Space, chosen Project, or Folder. This permission is typically granted with the Editor role.
You must also have access to at least one Organization Marking present on the store. However, access to the Project containing the store already requires access to one of the Organization Markings.
To create a local store, you must have the marketplace:create-local-marketplace operation in a Project or folder, which is usually granted with the Editor role.
Currently, remote stores can only be created by Palantir.
To create or edit products in a local store, you must have the marketplace:create-block, marketplace:edit-block-set, and marketplace:upload-attachment operations, which will usually be granted to the Editor role.
Remote stores are not editable in DevOps.
To export products from a local store, a user must have the marketplace:export-block-set operation, which will usually be granted to the Owner role. Currently, a user cannot export products from a remote store.
To import products to a local store, a user must have the marketplace:import-blockset-with-provenance operation, which will usually be granted to the Owner role. Currently, a user cannot import products to a remote store.
To edit tags on a local store, a user must have the marketplace:edit-local-marketplace operation, which will usually be granted to the Editor role. Currently, users cannot edit tags on a remote store.
All resources packaged in a Marketplace product are marked with one or multiple Organization Markings, usually inherited from the Project in which the resources are stored. Similarly, a Marketplace store is also marked with the Organization markings of the Project in which it is stored.
If the product resources do not have the same Organization Markings as the Marketplace store, you must obtain Expand access permissions for those Organization markings.
For example, let's say a Workshop application belongs to Organization A, and the store belongs to both Organization A and Organization B. The Expand access permission on Organization A is required to successfully package this Workshop application in the Marketplace store because you are extending the content from Organization A to Organization B.
If the product resources have Organization Markings that the Marketplace store does not have, you must obtain Remove permissions for those Organization Markings.
For example, imagine a Workshop application belongs to both Organization A and Organization B, and the store belongs only to Organization A. The Remove permission on Organization B is required to successfully package this Workshop application in the Marketplace store because you are removing (or unmarking) the Marking of Organization B.
As a user, you might not be authorized to view all Organizations to which a resource belongs.
In general, a Marketplace store must include all relevant Organization Markings for the Spaces into which you want to install. This means that a local Marketplace store must be located in a Project with all relevant Organization Markings for the Spaces into which you want to install.
For instance, if a Marketplace store only has Organization A's Marking and you want to install products of the store into a Space containing both Organization A and Organization B, you must obtain Expand access permissions for Organization A at installation time because you are extending the content from Organization A to Organization B.
During the installation, you can also opt to only apply Organization A's Markings to your product installation; this would eliminate the need for expanding access permissions.
Alternatively, you can add Organization B's Marking to the store, which would allow more users to install products from the store. For instance, if a Marketplace store has Markings from both Organization A and B, and you want to install products of the store into a Space containing only Organization A, no additional permissions are required. However, users with access to only Organization B will also be able to install products from this store.
In Foundry, you must have sufficient permission to move a resource from one Project to another by being the Owner of that resource, but you will also need additional permission on the Marking(s) involved if the move would expand the set of Organizations that can access the resources after the move.
For example, let's say a resource is in Project A, which belongs to Organization A, and you want to move the resource to Project B, which belongs to both Organization A and Organization B. You must have the Expand access permission on the Organization A Marking. Expand access is an elevated permission that allows you to expand the access of resources (belonging to Organization A in our example) to other Organizations (like Organization B).
If a resource has a Marking indicating PII other sensitive data, you must have the Remove Marking permission to remove that particular Marking.
If resources in Project A are packaged in a product stored in Project B, which is then installed in Project C, you must have sufficient permission(s) to both Expand Organization Markings and Remove additional Markings if any are present, since those Markings are removed during product movement.
To avoid friction during product creation, installation, and beyond we recommend the following:
This permission structure allows for any friction to occur at packaging time, allowing you to make necessary changes before the install process begins.