Hey Adam, Just found an example app designed to get started on a subdomain-based multi-tenant application. It uses subdomain-fu and authlogic and gets you started with scoping based upon a user's account_id. This will allow you to have any number of users accessing the same account.
http://github.com/devinterface/authlogic_subdomain_fu_startup_app Hope that helps. James On Wed, Oct 21, 2009 at 11:22 PM, Nick Zadrozny <[email protected]>wrote: > Hey Adam, > > Yeah, you're most of the way there with the account_id. My only suggestion > as far as the modeling goes (if you haven't already done it) is to finish > that out by actually modeling the Account object and using ActiveRecord > belongs_to and has_many associations to dry up your code a bit. > > Definitely work through some tutorials on authentication. I second the > AuthLogic recommendation, it's a popular plugin and has good documentation. > Authentication is a big part of account management, and it's not *too*huge a > conceptual leap to work in payment processing and account management > and the like. > > By the time you make it through a simple AuthLogic implementation (and the > signup forms and all that jazz) you'll have yourself a current_user or > current_account object in your controllers. From there it's just a matter of > making most of your models belong_to that currently-logged-in account. > > Oh, also, I suppose I'll share some personal preferences on modeling out > subscription software and accounts. I tend to model and authenticate an > account, but then also model a separate Person object to represent the > person actually logged in and using the software. It's a particularly useful > distinction if you want multiple users to share a single account, or if you > ever have people interacting with each other. > > Some basic models and associations to get you started… > > Account > - belongs_to :person > - belongs_to :subscription > - has columns for auth stuff like password digest > - has any/many/all other associated things > > Person > - has_one :account > - has_many :things that are tied directly to that person > - more personal stuff like name and contact info > > Thing > - belongs_to :person > - anything that this person was responsible for creating > > Common sights in such an app… > > @person = current_account.person > @things = @person.things > @thing = @person.thing.create(params[:thing]) > > Also, you mentioned subscriptions, so you may consider building out a > Subscription model as well as whatever else you need to track charges and > receipts. I'll be honest: payment processing can get to be a bit annoying ;) > > Subscription > - Stuff like price, feature level (possibly another associated object), > expiration date, etc > - has_many charges and receipts and all that good stuff. phew! > > And, lo and behold, we've gone from simple question to scope blowout! I > suppose that's what we engineers sometimes do best. > > Apologies for the excessive length and any lack of coherency, this is > something of a sleep-deprived brain dump for me. At any rate, hopefully all > this gives you some ideas, without being too redundant :) > > Have fun! > > -- > Nick Zadrozny > > > > --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
