Files and folders in Studio support fine-grained authorization based on ACLs (Access Control Lists). This section describes the file permission model, authorization methods, and effective scope, helping you limit access to and modification of development files based on team collaboration requirements.
Overview
File permissions in Studio are determined by two layers:
1. Role Permission Points (Project-Level): Control coarse-grained operations such as whether users can access the Studio module or create files through workspace roles. For details, see Members and Permission Management. 2. File ACL (Object-Level): Grant specific users or roles the Manage, Edit, Run, and View permissions at the folder or file level through ACLs. This document focuses on ACLs.
Prerequisites
You are the creator of the file or folder, or you have been granted the Manage permission.
Only objects under Workspace support ACL authorization. Objects under GitFolder do not support ACL authorization.
Your role must have the permission point to access the Studio module.
Permission Model
Permission Items
Permission | Capabilities included |
Management | View, run, and edit files; manage ACLs (add/delete authorization); delete, move, and rename files. |
Editing | View, run, and edit files; cannot manage ACLs; cannot delete files. |
Run | View files; run Notebook / SQL / Python files; cannot edit or delete files. |
View | Can only open files to view code and history; cannot run, edit, or delete files. |
None | Invisible. Files do not appear in the user's development directory. |
Permission Inheritance
A folder ACL is automatically inherited by its subfolders and files.
Child objects can override authorization individually. After the override, the ACL of the child object takes effect independently and is decoupled from the parent folder.
Default Authorization
The creator has the Manage permission by default.
Workspace administrators have the Manage permission on all objects under the Workspace by default.
Other users have no permissions by default (and cannot see the object).
Operation Steps
Step 1: Entering File Permission Configuration
1. Right-click the target folder or file in the Studio development directory.
2. Select Permission Configuration.
Step 2: Adding Authorization
1. In the permission configuration drawer, click Add Authorization.
2. In the Subject drop-down list, select User or Role, and search for the target username or role name.
3. In the Permission drop-down list, select Manage, Edit, Run, View.
4. Click Confirm to save.
Step 3: Adjusting or Revoking Authorization
Click Edit at the end of the row in the authorized list to modify the permission item.
Click Delete to remove the authorization of the user or role. After deletion, the subject returns to the No Permission state.
Step 4: Viewing Effective Permissions
The Effective Permissions list at the bottom of the drawer displays all users and permission items that have access to the current file or folder.
This list combines direct and inherited permissions for quick review.
Parameter Description
Parameter | Description | Required | Default Value |
Principal type | Select "User" or "User group". | Yes | None |
Principal | Username or user group name. | Yes | None |
Permission | Manageable / Editable / Runnable / Viewable. | Yes | Manageable |
Use Limits
Objects under GitFolder do not support ACL, and all project members have management permissions.
The Manage permission of workspace administrators cannot be revoked.
After a file is deleted, its ACL is retained along with the recycle bin record. After the file is restored, the ACL is automatically restored.
FAQs
Q1: A user has been granted the Edit permission but still cannot run the file in Workflow. Why?
Running a task in Workflow requires the Run permission on the file. If the run account for the task does not have the Run permission, a permission check failure is returned during submission or scheduling. Grant the Run permission or a higher permission to the run account as well.
Q2: If a user's Manage permission is revoked, will the subfolders they previously created be affected?
No. The ACL of child objects is stored independently. After the Manage permission is revoked, the user cannot manage new objects, but the ACL of existing child objects will not be automatically adjusted.
Q3: Which takes precedence, authorization to a role or authorization to a user group?
Both coexist. A user's final permissions are the union of the permissions of the user groups they belong to and their individual permissions. For example, if a user group is granted View and an individual is granted Edit, the final permission is Edit.
Q4: When a file is moved to another parent folder, does the ACL follow the child object or is it overridden by the new parent folder?
Both coexist. The ACL permission items of the child object itself are retained, and the permissions of the new parent folder are inherited. The permission items inherited from the original parent folder are removed.
References