Permissions
There are two positions on a Deployable: its owner, and anyone with access. There is no ladder of roles in between.
| Owner | Anyone with access | |
|---|---|---|
| Open and use it | ✓ | ✓ |
| Change the sharing scope | ✓ | |
| Add people and groups | ✓ | optional |
| Remove anyone’s access | ✓ | |
| Answer access requests | ✓ | |
| Invite an address with no account | ✓ | |
| Change source, entry file, version | ✓ | |
| Manage secrets and API targets | ✓ | |
| Delete it | ✓ |
Ownership
Section titled “Ownership”A Deployable is owned by the person who created it, or by a group, in which case the group’s owners manage it. Group ownership is what survives someone changing teams, so prefer it for anything a team depends on.
Letting others share it onward
Section titled “Letting others share it onward”Owners can turn on user sharing, which is off by default. It lets anyone with access add other people and groups. It does not let them change the sharing scope, remove anyone’s access, answer requests, or invite an address that has no account yet, since each of those either takes something away or reaches outside the organization.
Access is not in-app security
Section titled “Access is not in-app security”Every file Stackboard serves is available to everyone who can open the Deployable. Access controls who gets in, not what they see once inside. A section your app hides from some people is hidden in JavaScript on their machine and can be read out of the page.
If data shouldn’t be visible to someone who can open it, keep it out of the repository. Fetch it from an API that checks server-side, or split it into a separate Deployable.
Secrets are the exception. They are never sent to the browser, so someone can use a credential through the proxy without being able to read it.