TelemetryDeck v5: User and Organization Management

You can now be part of multiple organizations

Previously, a TelemetryDeck user always belonged to exactly one organization. That user could also see and edit all apps of that organization without any restriction. Only exactly one user of an organization – the founding user – could edit billing, manage users, and edit organization settings.

Today we’re updating that whole system. This has been months in the making, but I figured we’d need to pay that technical debt at some point, and now is the time. See below for a more technical explanation of our changes.

• Users can now be part of as many organizations as they want without having to log out and back it.
• If you’re managing an organization, inviting users works as before, but you can now select a new members Rolewhen you invite them.
• To switch organizations, select a new organization in the picker in the top left.

This feature is helpful for freelancers who work for multiple organizations, but also larger teams who are looking to split up their data a bit more. Try it out and let us know what you think!

Manage your organization members’ permissions

Each member of an organization has a Role that determines what that member can do.

• Users can work with apps, create insights, and see dashboards.
• Administrators can manage apps, billing details, organization access rights, and organization members.

To change a users’ role, look for them in the Members setting by clicking your name and then selecting Members.

Under the hood, our system supports arbitrary roles and more fine-grained permissions. We’ll be looking to expose those in the UI over time.

More predefined insights

I’m sure you already noticed additional items in your app overview sidebar. These are predefined insights that we’re building for all our customers. We’re working with data science experts and developers to see what are the most important numbers that all app makers really need to keep in mind.

So far we’re showing these items:

• Devices: an overview over what kinds of devices are running your application, on which operating systems. Really important for future planning.
• Versions: an insight into which versions of your app are being used, and which versions of the TelemetryDeck SDK they are using.

We want to explore more in this area and I wholeheartedly encourage you to reach out via GitHub https://github.com/telemetryDeck/issues/issues with feedback and ideas for upcoming predefined insights.

We fixed some bugs

"Bug fixes and performance improvements" is just the best release message ever right? Here’s a quick excerpt of tickets we’ve closed while working on this version:

• Fix: The app drop-down doesn't show newly created apps
• Fix: Granularity Picker is marked as inactive when it shouldn't be
• Only Request Org Notifications when user is logged in
• 🚀 Fix truncated chart labels
• 🚀 Fix insight editor saving issues
• Fix a non-working granularity picker
• 🚀 Display single raw values
• 🚀 Fix legend ordering in some carts
• Display a default value for new TopN insights
• Fix: Editing insights changes their order
• 🚀 Allow renaming apps
• 🚀 Allow exporting signals data
• Sort most dropdowns
• 🚀 Collapse sidebar on mobile devices
• Fix missing space between insights on mobile devices
• 🚀 Allow scrolling in Recent Signals view
• Use gravatar for user avatars

The permission system

When we started working on this new permission system, it became clear pretty quickly that this would be a breaking change that would affect all our APIs and how clients would interact with them. It would be disruptive. So I wanted to make really sure we wouldn’t have to make changes to this part of our database schema often. Instead, I wanted to have a schema that is extensible and reasonably future-proof.

This is what we came up with, and I believe this should work pretty well for a while.

In this version, we have Apps that belong to Organizations, same as before. However, users don’t belong to any organization any more. Instead, they have an association with one or multiple Roles. These roles then belong to an organization. This way, users can be parts of multiple organizations.

What we can see now

However, this structure also allows us to encode permissions. The two types of permission we’re looking at are Organization Permissions –– the ability to modify or administrate the organization in any way, such as by adding apps or managing users — and App Permissions — the ability to manage, edit, or view individial app inside an organization. Both sets of permissions allow values of none, read, write, and administrate.

Organization Permissions are defined by the role a user has within an organization. If a user’s role has administrate permissions for an organization, that user can manage billing or users for example.

App Permissions are defined by an organization’s base permission level: the base access for all apps inside an organization. There is more coming, but this is as far as the UI currently exposes this new permission system:

What’s coming in the future

Looking at the UI, every organization has roles named “Administrator” and “User” and can assign their members to one of those roles. There is currently no way to create additional roles in the UI, and no way to change an organizations app base permissions.

Our updated schema also allows us to encode individial permisssions that roles have for apps. These overwrite the organization’s app base permissions. For example, an organization could decide to set their app base permissions to “none” and then create one role per team, and only allow access to the apps relevant to that team.

I’ll be thinking more about how and when to expose this functionality to our customers. As always, your feedback is incredibly welcome!

For now, thanks so much for your continued support. I’ll see you online!