Rethinking Roles

Sentry has a long history of building features to add support to complex organizational security. It's
the reason we support things like multiple and revokable client keys, teams,
and a variety of ways to limit the scoping of actions. Somewhere
along the way, however, we feel we went a bit too far with our permission
matrix. It became too complicated for the average user. Today that is changing
with our new Roles.

Some History

The way roles used to function is by describing two attributes, team access
and a membership level, we would compute which scopes and object permissions
you had. This worked fairly well on the backend, but for the user experience
it was confusing. A primary example is that giving ownership access to an
organization required both ticking the has global access box in addition
to setting the Owner role. This led to far too many support tickets, and
eventually documentation that even we ourselves weren't satisfied with writing.

Never was it clear which level of permission you would need to grant to
members in order to allow them to do certain tasks such as creating new teams
or adding members. It was obvious a change was in order.

Introducing Roles

Today we are releasing a new Roles feature to replace the old-style permission
computation.

The new rules consist of four primary levels:

Owner
The owner acts exactly like you would have expected it to previously. It has full permissions across the board.

Manager
Identical to the owner but with one key restriction: they cannot submit an organization delete request.

Admins
Admins lose the ability to perform organization-wide affects. They can create and remove projects (within their teams), as well as create new teams (thus becoming members of them).

Member
Nearly identical to before. They receive the ability to interaction with events and in some cases, read-only access to project settings.

Additionally for Hosted Sentry we've got you covered for accounting, with the new Billing role.

Team Membership

The last piece of our puzzle is team membership. When Sentry began the only way
for a member to join a team was by having an administrator invite them. Along
the way we improved this significantly by adding the ability for users to
request access to an existing team. We then improved it even further by
allowing you to set Open Membership within an organization's settings,
thus allowing anyone to join and leave teams whenever they wanted.

Today we're making one more significant change to membership: Owners and
Managers will no longer be automatically added to new teams. They'll
always be able to join a team without approval, but it'll no longer happen
by default. This means that in large organizations the team responsible for
managing the organization no longer has to deal with negative side effects.

Unless your company happens to building highly sensitive mobile phones, we feel
the best experience you can give your team members starts with enabling Open
Access and Single Sign-On. From there let Sentry run on auto-pilot.

Looking Forward

We're going to continually be evaluating our access controls and simplifying
things where it makes sense. We already see some obvious improvements if we
were to combine several of our more granular scopes. An example of this would be merging team:write and team:delete into team:admin.

As always, we'd love to hear your feedback. Whether you want to debug Python, do PHP error tracking, or handle an obscure JavaScript exception, we'll be working hard to provide the best possible experience for you and your team with Sentry!