DropConfig has several levels of role-granularity.
You can grant access to collaborators on an org-level. Also members of an organization can have more granular access permissions for the repositories within the org, or for individual configs inside org’s repositories.
If a person has multiple avenues of access to an config (through config-level role, repository-level role, or org-level role), the highest permission level overrides lower permission levels.
You can see all roles the person has within your org on the user’s profile page.
Organization members can have owner, admin, billing, or member roles.
Owners have complete administrative and billing access to your organization, while billing managers can only manage billing settings.
Admins have complete administrative access, but no billing access.
Member is the default role for everyone else, and gives no access to org’s repositories and configs.
Repository members can have admin, developer, content-manager or viewer roles.
Repository viewer can view the content of every config in the repository, but can not modify values or structure. Viewer also can not publish older versions of config.
Content-manager can do everything that viewer can do, and additionally can change values of the config without changing its structure. Content-manager can also publish newly created config versions, as well as choose and publish previous config versions.
Developers have complete control over configs, including changing the structire of configs. They can also create new configs in the repository.
Admins have complete control over configs in the repository, and also have complete administrative control over the repository.
On the level of individual config you can only grant content-manager role.
Content-manager can see config’s content, and can make modifications to config’s values without changing config’s structure. Content-manager can also publish new or old versions of the config.