Permissions
Authoring and executing Functions in the platform is subject to many kinds of permission checks. This section outlines the different types of permissions you should be aware of and common issues you may run into.
Function authoring
Functions repositories must be granted appropriate permissions to:
- Access the Ontology so that proper code bindings can be generated.
- Load objects in order to run a Live Preview of a Function execution.
Note that repository permissions must be explicitly granted, and are not the same as the permissions granted to your user account. As a result, you have to take specific steps to import object types, link types, and backing datasources into the Project that contains your repository.
For a tutorial on these steps, see this section. Below, we explain the specific resources that are imported and the permissions granted for those resources.
Ontology entity permissions
In a repository, whenever checks run or Code Assist starts up, the Functions plugins load the latest Ontology based on the repository’s permissions and generate code bindings for every object and link type that was loaded. The set of object and link types that are loaded depends on the imports of the following resource types:
- Ontologies
- Ontology branches
- Object types
- Link types
In a Functions repository, you can import the needed Ontology resources by navigating to Settings > Ontology. This interface allows you to choose object and link types to import into your Project.
If your user account has access to multiple Ontologies, you can also choose which Ontology you’d like to use. Currently, importing multiple Ontologies into a single Project is unsupported.
Although the above interface shows up within Functions repositories, any Ontologies, object types, and link types you import are added at the Project level. This means that changing imports in one repository can affect other repositories in the same Project. If you want to have two repositories that rely on different Ontology entities, you should separate them into different Projects.
Object loading permissions
The Functions helper in a repository allows users to execute Functions in two ways: by executing a published Function, or by executing code in Live Preview. When executed in a Live Preview, Functions code is compiled and executed in Code Assist, which is infrastructure designed to enable quick iteration for code authors.
Because it is tied to the repository, Code Assist is subject to the same permissions requirements as code generation, as described above. This means that when running a Function in Live Preview, the backing datasources underlying each object type you wish to use must be imported into the Project.
In the Functions helper, if there are object types imported into your Project without the corresponding datasource being imported, a warning will be displayed in Live Preview prompting you to update the imports:
In the case of most object types, the Import backing datasources dialog will prompt you to import a Foundry dataset. For object types that have row-level security enabled, you will be prompted to import a Restricted View.
Published Function execution
Once a Function has been published, it is ready for use by a broader audience of users and can be configured to execute in applications such as Workshop and Actions. There are still some considerations to keep in mind for permissions to execute a published Function.
Function permissions
In order to execute a Function, a user must have Viewer role on the repository from which the Function was published. Typically, it is best to locate Functions repositories in the same Project as end-user applications that rely on Functions in that repository, whether those applications are created using Workshop, Slate, or some other tool. If users encounter errors indicating that they lack permissions to read a Function (ReadFunctionsPermissionDenied), check whether they have read access to the repository. Learn more about how to move and share resources.
The Check access panel in the sidebar can be used to check someone's access to a Workshop or Slate application, including access to dependent functions. For more information, see the Check access panel documentation.
Function-backed Actions are a special case in which end users do not necessarily need read access to the Function in order to apply an Action that uses it. An administrative user must have read access to a Function when configuring an Action to use it. Afterwards, users will be able to apply the Action based on Action-level permissions, regardless of their access to the Function.
Object loading permissions
When a Function loads object data, either as a parameter or via an Object search, the permissions of the end user running the Function determine which objects are loaded. In the case of object types secured using row-level permissions, this means that different users executing the same Function may receive different results. This behavior is intended—users should only see the objects they have access to, and this behavior enables a single Function to work for users with differing access to individual objects.