title: Django: multiple accounts, with multiple users under each account, but account-specific data
body: <p>Using Django 1.5 here.  I have an application I've created that currently has one big set of data, for one "account" if you will.  Meaning all the data in all the models in my application are available to all logged-in users.  Now, I want to be able to allow more people to use my application but with their own set of data.  So I need to separate users into different accounts with different sets of data for each account.  There could potentially be one or multiple users that has access to each account.  At this time I don't need different users within one account to have different levels of access though I do intend for one user to be the account "owner".</p>
  
  <p><img src="https://i.stack.imgur.com/semOg.png" alt="enter image description here"></p>
  
  <p>I know that to make this conversion, I of course need to add a field to every model with a foreign key to a new "account" model.  But beyond that I'm a little foggy.  This appears to be a square peg in the round hole of Django's auth system.  So the question is, what is the best approach?</p>
  
  <p>A few thoughts I had so far:</p>
  
  <ul>
  <li>Simply filter each and every query by account</li>
  <li>Wrap each and every view with a decorator, but with multiple models, do I have to create a different decorator for each model?  Can I tell from within the decorator which model is being accessed?</li>
  <li>Somehow make use of the Auth system's <code>user_passes_test</code> decorator, but again, different models.</li>
  <li>Extend the auth system to include a <code>request.account</code> attribute</li>
  <li>Create a new mixin for my views?  What if I'm not using exclusively CBVs?</li>
  <li>Different middleware?</li>
  </ul>
  
  <p>I considered using a new group for each account and then filtering by group instead of a new account model but I predict that would be a poor fit in this situation, as it isn't using groups as they were intended.</p>
  
  <p>This is less of a code question and more of a big-picture, best-practices question.  How would you approach this?</p>