Trying to think of the cleanest way to implement this.
I'm writing out the Schema for an internal application which involves
Sales people requesting Production Orders from Production People.
If someone's just a sales person, they should land at the sales layout
with only their client accounts.
If someone's a sales person and an admin, they should land at the sales
layout with everyone's accounts.
If someone's production or production with admin, they should land at
the production layout.
So I'm trying to think of the best way to do this. Right now users have
an "is_admin" option in my Users table, so that's fine. But what about
the account types of either Sales or Production?
Do I create a Sales table and a Production table and add Users to those
tables? Checking against those tables to see if that user is a member of
it?
Or should I create an account_types table, ad sales and production as
records and check against which account type they have?
Or is there an even better solution?
With the first two I listed, it's very possible there will be a third
account type I need to add later. That means I'd have to either create a
new table for each account type, or if I just add those types to the
account_type records, what happens if someone goes in and deletes one of
the records and I have code checking to see if someone is that type?
When you have several entities that are almost the same, but not quite,
then using sub- / superclasses might be a good idea.
When a user is either a regular user or an admin, then the boolean flag
on the user model is fine, but when you start to get several user types,
then I think its better to make subclasses of user for each type.
Just add a new field to the user model "type" (string) and then you can
create one model for each user type, like
class SalesPerson < User
end
Once that is done you can pretty much treat the models as if they had
separate database tables.
If you do SalesPerson.new, then rails will automatically set the type
field to "SalesPerson". If you do SalesPerson.find, rails will know to
look in the users table where type is SalesPerson.
The great thing here is that you can have separate models for each user
type, without needing a bunch of tables with all the same fields, and
you can add logic to the user model that are inherited by all the user
types for the logic that the they share.
One warning though:
Dont try to operate on user.type, this will create weired error
messages.
If you ever need to access that field directly, use user['type'].
Thanks for the 'a-ha' moment - I am actually trying to work out how to
do just this kind of thing for authentication and privilege granting.
Pardon the Newb follow on question - how would you handle the class
issue in a login scenario? With subclasses, I don't know how you could
implements something like:
If User.isadmin?
... stuff admins can do or see
Else
... etc.
The Agile Web Dev Book talks about single-table inheritance, but I'm a
little confused - is it as simple as just looking at User and letting
Rails Magic (TM) figure out the type of user and return the
appropriate subclass? Users can log in and Rails works out which
subclass to use automagically based on the initial setup of the user
in the database?
Checking what type of user is logged in is as simple as
current_user.class.
Rails doesnt "use a subclass", like its faking anything, the object is
truly an object of that class. If you do User.find(1).class it might
tell you that it is a moderator object or an admin object, or a user
object(if type is nil).
The magic lies in the fact that several models are stored in the same
database table. The models themselfs works like regular sub/super
classes.
This can be a bit tricky to understand at first. The best way to learn
it is to actually try to implement it yourself.
Once that is done and you know how tell which type of user is logged in,
you may want advice on how to implement role based authorization. This
link will help:
Checking what type of user is logged in is as simple as
current_user.class.
Rails doesnt "use a subclass", like its faking anything, the object is
truly an object of that class. If you do User.find(1).class it might
tell you that it is a moderator object or an admin object, or a user
object(if type is nil).
The magic lies in the fact that several models are stored in the same
database table. The models themselfs works like regular sub/super
classes.
This can be a bit tricky to understand at first. The best way to learn
it is to actually try to implement it yourself.
Once that is done and you know how tell which type of user is logged in,
you may want advice on how to implement role based authorization. This
link will help:
#188 Declarative Authorization - RailsCasts
I've found this thread really useful. I tried a small example last night
and it worked it will help me on my next project so thanks guys.
it will help me on my next project so thanks guys.