Access levels

A rule gives one person or one group a level on one bucket or one folder.

The level is what they may do there. Four levels grant access and two take it away, and a rule covers the folder you name and everything under it — so a rule on the bucket itself is the default for the whole bucket, and a rule on a folder inside it refines that.

Rules only matter on a restricted bucket. A bucket is open to the whole workspace until you mark it restricted on its Permissions tab.

Read & write — everything the person's workspace role allows. The role is still the ceiling, so a *member* with Read & write can add, replace and rename, and still cannot delete.

Contribute — for people who should add to a folder without being able to take anything out of it. They see and download what is there, and add more.

Read-only — look and download, change nothing.

Upload only — a drop box. The folder opens with the upload panel ready and an empty list, which is the point rather than a fault: they cannot see, download or search what is in there, not even the files they sent themselves. They can create folders inside it to organise what they send.

No changes — a block that keeps someone reading a folder while every upload, rename and delete in it is refused.

No access — a block that hides the folder completely. It does not appear in the listing at all.

Only Read & write can upload over a file that already exists. Contribute and Upload only are refused and asked to pick another name:

> "report.pdf" is already there, and your access to this folder lets you add files but not replace them. Upload it under a different name, or ask an admin for full access to the folder.

Replacing a file destroys the old contents exactly as deleting it would, and most buckets have no versioning to recover from. A level defined by *not* being allowed to delete must not hand that back through the upload button.

If people genuinely need to replace files, give them Read & write. On a bucket with versioning switched on, a replaced file can still be recovered — BucketPilot shows every version of a file when the bucket keeps them.

To name a bucket or folder as the destination of a backup or a migration, you need Read & write there. Contribute and Upload only are not enough, because a job overwrites whatever it finds — it is a standing instruction that runs later, unattended.

The source side needs read: Read-only, Contribute or Read & write all work.

A job you cannot create for this reason is refused when you save it, not when it next runs, so you find out while you are still looking at the form.

• •A block always beats a grant, at any depth. Read on reports/ with No access on reports/payroll/ means everything except payroll.
• •The deepest rule wins among grants. Read-only on the bucket and Read & write on reports/incoming/ means they can add files in that one folder and only read everywhere else.
• •Rules name folders, never single files. A rule on one file would stop applying the moment it is renamed or re-uploaded, so a scope that names a file is refused.
• •A group and a person can both have rules. Everything they are granted adds up, and any block still wins.
• •Admins are not affected. Rules shape what *members* can reach; an admin always has full access to every bucket in the workspace, and your own personal buckets have no rules at all.

A client sends you files, and never sees anyone else's.
Mark the bucket restricted. Give the client's group Upload only on incoming/acme/, and your own team Read & write on incoming/. The client opens one folder, drops files in, and sees an empty list — including no sight of their own earlier uploads, and none at all of the other clients beside them.

A contractor writes reports but cannot remove anything.
Give them Contribute on reports/. They read the back catalogue, add this month's file, and cannot delete, rename or overwrite what is already there. If they need to correct a file they just sent, they upload it under a new name — or you give them Read & write once the work is trusted.

An auditor reads everything except payroll.
Give them Read-only on the bucket and No access on finance/payroll/. They browse and download the whole bucket, and the payroll folder is not in the listing for them at all.

A finished archive nobody should touch.
Give the whole team No changes on archive/2024/. Everyone keeps reading and downloading it, and every upload, rename and delete in it is refused — including from people who have Read & write on the bucket, because a block always wins.

Each team works in its own folder.
Give every group Read-only on the bucket so they can see the shape of it, plus Read & write on their own folder. The deepest rule wins, so each group edits only its own work.

An access level never widens someone's workspace role.

• •Admin — everything, including deletes and credentials. Rules do not apply to admins.
• •Member — browse, download, upload, rename, move, run jobs. A member cannot delete anything shared, whatever level they hold.
• •Read-only — every write is refused, whatever level they hold.

So a member holding Read & write on a folder can do everything in it except delete, and a read-only person holding the same level still cannot change a thing. See Roles.

• •"You don't have access to this folder" — there is no rule granting them that folder, or a block covers it.
• •"…lets you add files but not replace them" — Contribute or Upload only, uploading over a file that already exists.
• •"Only organization admins can delete resources or manage credentials" — their role, not their level: they are a member.
• •"Your role in this organization is read-only" — their role again: read-only.
• •The folder simply is not listed — a No access block, which hides rather than explains, on purpose.

Every refusal is recorded in the workspace's activity feed with who, what and when, so an admin can see what someone has been trying to reach.