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? Suggestions? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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'']. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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? Thanks! SR On Feb 3, 12:56 pm, Sharagoz -- <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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'']. > -- > Posted viahttp://www.ruby-forum.com/.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
>I''m a little confusedChecking 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: http://railscasts.com/episodes/188-declarative-authorization -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Sharagoz -- wrote:>>I''m a little confused > 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: > http://railscasts.com/episodes/188-declarative-authorizationI''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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.