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!