Set user permissions for files, folders, and metadata

You can set permissions for files, folders, and metadata in hila. Permissions are set by user or by role.

Permissive default permissions

By default, hila opens permissions on new files, folders, and metadata to all users. This means that all users can ask questions against documents in open folders and against databases that admins have added to the system.

Creating files and folders through Data sources and Data Manager have some default permissions as follows:

• Any folder created by a user in the Data sources window, and any documents loaded into that folder, are accessible only by that user and all admins.
• Any folder created by an admin in Data Manager, and any documents the admin loads into that folder, are accessible only by admins.

Modify permissions on hila objects

Given that hila uses open permissions by default, your fine-grain control involves first excluding users and then adding permissions for the users you want to include.

The following JOSN object passed with the POST /v1/object-permissions API call sets permissions for a file, folder, or metadata object:

{
  "uncname": "string",
  "owner": "string",
  "user_role": null,
  "create": true,
  "read": true,
  "update": true,
  "delete": true,
}

• uncname — The name of the object to set permissions on. The format is “

  • is the file path to the object whose permissions you want to set.
  • For example:
    • “uncname”: “file:/folder1/folder2/file1.pdf”
    • “uncname”: “folder:/folder1/folder2”
    • “uncname”: “qna_metadata:/metadata1”
• user_role — The username or role to set permissions for.
  • If you set a role, all users with that role have the permissions you set.
  • If a user is in multiple roles, the user only needs permissions set in one role to have those permissions.
  • An asterisk (*) represents all users.
• create, read, update, delete — The permissions to set for the object. Set to true to allow the permission, and false to disallow the permission.

Examples

Example 1

Let’s say you want to restrict full access to a group of users.

1. Close permissions on the object by posting the following JSON to /v1/object-permissions:

    {
    "uncname": "file:/folder1/folder2/file1.pdf",
    "owner": "<owner>",
    "user_role": "*",
    "create": false,
    "read": false,
    "update": false,
    "delete": false,
    }
   

2. Create a role and assign the users to that role. See Users, roles, and permissions.

3. Set the new permissions with the following JSON:

    {
    "uncname": "file:/folder1/folder2/file1.pdf",
    "owner": "<owner>",
    "user_role": "<role or username>",
    "create": true,
    "read": true,
    "update": true,
    "delete": true,
    }
   

   Example 2

Let’s say you want a group of users to be able to ask questions against a database, but you don’t want them to be able to create, update, or delete the metadata, then you can set read-only permissions on the metadata object.

1. Create the role and assign the users to that role. See Users, roles, and permissions.

2. Restrict permissions on the metadata object by posting the following JSON to /v1/object-permissions:

    {
    "uncname": "qna_metadata:/metadata1",
    "owner": "<owner>",
    "user_role": "<role>",
    "create": false,
    "read": true,
    "update": false,
    "delete": false,
    }