Permissions explained
Three levels (read, write, manage), one resolution function. How owners, ACLs, folders, groups, and restricted folders combine into the effective level on any doc.
sweetdocs uses three permission levels and one resolver function. Once you understand the resolver, every “why can / can’t I do X here” question has a clean answer.
The three levels
| Level | What it lets you do |
|---|---|
| Read | View the document (including images, tables, code blocks). Cannot type. Cannot add comments in v1. |
| Write | Everything Read can do, plus: edit the body, add and resolve comments, see real-time peers, attach images |
| Manage | Everything Write can do, plus: change the document’s sharing (public link toggle, invite people, change levels, remove access), rename the doc, change its folder |
That’s it — there’s no separate “comment-only” role and no level above Manage. Ownership is a separate concept that grants automatic Manage (see below).
How your level on a document is determined
The server-side function effective_level(user, resource_type, resource_id) returns one of read, write, manage, or null (no access). Every read and write in the app and the database flows through this function.
The resolution runs in this order:
1. Ownership shortcuts
| Library type | Who automatically has Manage |
|---|---|
| Personal library | The library owner; the document’s creator |
| Org library | Org Owner and Admin roles (every doc in the org library) |
If you match one of these, the answer is immediately Manage. Nothing else is checked.
2. The folder chain
If you’re not an automatic Manager, the resolver walks the folder hierarchy upward from the document. For each folder it finds, it checks whether you (or any group you’re a member of) has an ACL entry on that folder.
Restricted folders cut the chain. If the resolver hits a folder marked restricted during the walk, it includes that folder’s ACL but stops there — no further-up folders or the library are considered. This is how a private folder inside a shared library stays private to the people explicitly added.
3. Library ACL
If no restricted folder cut the chain, the resolver also includes the library-level ACL. This is the standing access that members of a workspace library all share.
4. The highest level wins
After collecting every ACL entry that applies to you (direct user grants + grants on any group you’re in), the resolver returns the highest level. So if a folder grants you Write but the library grants you Read, your effective level on the document is Write.
Group ACL grants
When you add a group to the ACL on a doc, folder, or library, every member of that group inherits the grant. Adding a user to the group later automatically extends the grant.
Conversely, removing a user from a group drops their group-based grants — though any direct user grants they have still apply.
Who can change sharing
The People and Link tabs in the share dialog require Manage on the resource. Read and Write collaborators can see the current state but the controls are disabled. The dialog explicitly says:
You need Manage access to change the public link.
…when the user can’t change it.
Who can delete a document
Soft-delete (moving to the Recycling Bin) requires write access; the deleted_by field is recorded against your user.
Permanent delete (purging from the bin) requires Manage — typically the owner. See Recycling Bin.
Folders + cascade
Sharing a folder cascades to all the documents inside it. So if you share a folder with someone at Write:
- Every document currently in the folder gets Write for that user
- New documents created in the folder later get Write automatically (no re-sharing)
- Subfolders inherit the share too
- A restricted folder inside the shared one does not inherit (its ACL is independent)
This is the easiest way to share a body of work with a team: organize into a folder, share the folder once.
The Share dialog’s view
The People tab shows what’s been explicitly granted on this resource — direct user grants and group grants on the doc itself. It does not show inherited grants (from folder shares, library access, or org membership). Those are still in effect, just not editable from this dialog.
To change an inherited grant, navigate to the resource it was granted on (the folder, library, or org) and edit there.
Public link viewers
A viewer using a public link doesn’t have an account-bound level — they have anonymous read access on that specific URL. They show in the audit timeline as anonymous view events. They can’t comment or interact beyond reading.
What changes inside an org library
When an org owns a library (instead of an individual user):
- The personal “library owner has Manage” rule does not apply
- Org Owners and Admins get automatic Manage instead
- Org Members get whatever the library/folder/doc ACL explicitly grants — no automatic level
- Org Members are still subject to the same folder + group + restricted rules
This means org workspaces enforce least privilege by default: a new member sees nothing until they’re added to a library, folder, or group, then sees only what those grants allow. See Organizations for the org-level model.