Refactoring lessons: Making more flexible permissions

We're in the early process of re-architecting DoneDone, our simple web-based issue tracker. Since we launched in April 2009, we've gotten plenty of your feedback on what's working and what's not. Now, we've reached that exciting, but admittedly daunting decision to redesign a lot of the inner-workings of DoneDone.In this post (and likely a few more), I'll introduce some major architectural changes we're contemplating. I hope it provides insight into our thought process and a chance for the community-at-large to cheer us on or raise a red flag.Let's talk user permissions.

DoneDone and user permissions

When I first started building DoneDone in the Fall of 2008, we decided to make permissions very simple and rigid.

Current model of a given DoneDone account (C = company, U = user, P = project, I = issues)For any given DoneDone account, a user (Tom) must belong to a company (We Are Mammoth). A company has access to a project ("ACME web site design"). Within a project that a user's company has access to, the user can see all issues. The model looks roughly like this:These permissions were intentionally rigid. In the beginning, we felt this was a good way to promote transparency between small companies working together. Everyone in a company has to see every issue in a given project.But, a lot of you (including us) wanted to include only a few people from within a company on a particular project. Or, you wanted to bring in a contractor, who didn't fit under a company name, into a project. You also might want to hide some issues from particular people in a company. There were many reasons why we needed more flexibility in managing people's permissions to specific projects, or even specific issues within a project.

Project and issue permissions revolve around the user

Refactor #1: Revolving permissions directly around the user

In our first refactoring attempt, we followed a more traditional model, like the one you see in Basecamp. Now, our permissions for a project, or issues within a project, point directly to the user while removing the dependency off of the company.This model still gives us the ability to assign whole companies to projects on the UI — we'll store them as multiple user-to-project relationships instead of 1 user-to-company relationship. But now, we can also use the user-to-projects or user-to-issues relationships to specify user access to whole projects or just specific issues. Problem solved.

Sharing projects amongst multiple accounts

We wanted to take permissions one-step further — we'd like to let users share projects between different accounts. This is something we've found frustrating with other web-based apps.Here's an example. We use Basecamp to manage web projects. When we work with a client, we'll typically create a new project in our company's Basecamp account, and then create user accounts for each participating member of our client company.But, often times, our client already has its own company Basecamp account. So, we have to decide whose company account gets to own the project. This means that, for some clients, we need to log in to a different Basecamp account to work on a project together. 37signals recently released "LaunchPad", an interface that aggregates all Basecamp accounts, so you can easily toggle between one account and another. But, it doesn't truly let you share a project amongst multiple accounts.DoneDone suffers from the same limitation. Here's our approach to fixing it.

Refactor #2: Switching to a multi-tenant database model

Currently, DoneDone uses single-tenant database architecture.The first pill we have to swallow was a big one: We have to go from single-tenant databases to a multi-tenant database. Single-tenancy has its virtues. For one, it let us not worry about permissions between accounts. All projects, issues, or users belong to a specific account because accounts are partitioned by their physical databases.But, if we have any reasonable chance of sharing projects between different accounts elegantly, we have to go with a multi-tenant database in our refactor. As a result, we now have to introduce the concept of "accounts" within the data schema instead of relying on the physical partition to handle accounts.

Defining the new multi-tenant model relationships

Refactor #3: Defining new account-level relationships

With accounts introduced, there are two new relationships we can create — accounts-to-users, and accounts-to-projects.First, accounts relate to users. This lets us permit the right users to the right accounts in the multi-tenant model (something that was simply handled by the division of physical databases in the single-tenant model).Second, accounts relate to projects. However, we'll use this relationship to determine what account is responsible for the billing associated with the project, as opposed to access. Access to the project is solely determined by the aforementioned user-to-project relationship from refactor #1.As an admin to a project, a user can invite other users not just within their accounts, but within any DoneDone account, via their email address. But, when a user logs in, they can do so via their account rather than having to log in through the project owner's account.My hunch is that other web-based multi-tenant products have tied the "account-to-project" relationship to access, as opposed to just ownership, very early in the development game, and have since built too much logic and relationships on top of that premise. I know, for example, that 37signals has admitted to sharing projects across accounts as a "deep change."

The end result

With these specific refactorings, we hope this version of DoneDone will solve a lot of the permissions hurdles you may have faced over the last couple of years.We'd love to hear your perspective, comments, or questions on these early design decisions. It will certainly help us evaluate whether we're going in the right direction. We want to make sure the new version is something we can continue to build off of for years-to-come.As always, follow us on Twitter or talk to us at GetSatisfaction.