Permissions

A permission grants actions to users and groups through rules, at most one per kind:

The actions are read, annotate, deploy (write), delete, promote (releases) and manage (all). Setting properties needs annotate, also when an upload sets them (?k=v on the Relic API, ;k=v on the Artifactory® deploy route). Creating a release also needs read on its content; promoting one needs write on the target repositories.

Administrators can do everything; other users, what a rule or their project role grants. An item's Permissions tab shows who may do what on it.

A repository a user may do nothing in, and a build they may not read, answer 404 as if they did not exist, on the package manager routes as on the Relic API. A missing action on a repository the user can otherwise use answers 403.

All, all local and all remote leave out the repositories Relic writes itself (build information, releases and evidence); a repository rule reaches them only by naming them. Build and release rules govern access to builds and releases.

A viewer sees the administration and security pages without changing them, and gets no repository access: lists of repositories show a viewer only those a permission lets them read. Turn on Viewer for a user, or Viewer privileges for a group.

User and group names are unique ignoring case: Relic refuses ENG TEAM while Eng Team exists, because single sign-on, LDAP and SCIM match group names ignoring case.

A user's email is empty or a single address such as alice@example.com. The Relic API, relic apply and the Users page refuse any other, such as Alice <alice@example.com>.

A grant names a user or group that exists already.

Manage permissions in Administration → Permissions, or declare Permission resources and run relic apply.