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 -~----------~----~----~----~------~----~------~--~---
