Permissions and Roles

Permissions define two separate things:

1. What a user can do
2. Where they can do it

Do not treat roles as global trust. Role + scope is the real control.

Authorization modes

SynckHub deployments commonly run one of two authz behaviors.

Community mode (repo-level)

Community mode is repo-scoped.

• If you have a repo role, you can see the whole repo tree.
• Default role levels are typically:
  • READER
  • WRITER
  • ADMIN

Use this when you want a simple Git-like boundary at the repository level.

Enterprise mode (folder/item-level)

Enterprise mode supports fine-grained access.

• Access can be granted at folder and item scope.
• Members may have access to selected areas but not the full repository.
• Sharing behavior is explicit and auditable.

Use this when teams need strict least privilege and controlled external collaboration.

Action model (what permission actually means)

UI labels vary by deployment, but capability maps to actions such as:

• READ_FOLDER: browse folder listings
• READ_CONTENT: read item bytes/content
• WRITE_CONTENT: edit content
• TRASH_RESTORE: move items to trash or restore them
• EXPORT: bulk download/export
• FEDERATE: create or manage federated sharing where enabled
• MANAGE_PERMISSIONS: change sharing rules

Important: READ_FOLDER and READ_CONTENT are separate concerns. A user may browse a folder without being allowed to read every item’s content.

Common preset model

In the fine-grained permissions UI, SynckHub commonly presents these presets:

• Viewer
  • browse folders
  • open items
• Downloader
  • viewer access
  • export folders
• Basic editor
  • viewer access
  • edit content
  • rename and move
  • create files and folders where folder scope allows it
  • delete via trash/restore
• Editor
  • basic editor access
  • export
  • federate where the deployment exposes federation controls
• Manager
  • editor access
  • manage permissions/sharing

These are convenience bundles over the underlying action model. Rules are still stored and evaluated as explicit actions plus scope.

Simple vs advanced permissions editing

• Simple mode uses shared presets for the common folder/item combinations.
• Advanced mode exposes the underlying scope splits directly:
  • this folder
  • child folders vs child items
  • subtree folders vs subtree items
• If a rule set no longer matches a predefined bundle exactly, the UI shows it as Custom.

Inheritance and boundaries

• Folder rules usually propagate to descendants unless overridden by policy.
• Item-level rules can narrow or specialize access.
• Path links never bypass permissions; access is always checked at request time.

Practical role assignment pattern

1. Grant access at folder scope, not root, unless root access is required.
2. Start with read-only where possible.
3. Add write/export/manage capabilities only when workflow requires them.
4. Re-check guest and external access regularly.

Frequent mistakes

• Granting broad root access for convenience.
• Using export permissions too broadly.
• Assuming a link grants access.
• Letting temporary collaboration access become permanent.

Quick audit checklist

• Can users open only what they should?
• Can guests access only intended folders/items?
• Can only trusted owners/admins change permissions?
• Can only intended users export bulk content?