# Design Advice

**URL:** <https://www.ruby-forum.com/t/design-advice/182843>\
**Category:** Rails\
**Created:** [February 3, 2010, 7:26pm UTC](https://www.ruby-forum.com/t/design-advice/182843 "2010-02-03T19:26:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jooma2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9bcb4/32.png) [@jooma2](https://www.ruby-forum.com/u/jooma2)\
**Post date:** [February 3, 2010, 7:26pm UTC](https://www.ruby-forum.com/t/design-advice/182843/1 "2010-02-03T19:26:12Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jooma2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9bcb4/32.png) [@jooma2](https://www.ruby-forum.com/u/jooma2)\
**Post date:** [February 3, 2010, 7:56pm UTC](https://www.ruby-forum.com/t/design-advice/182843/2 "2010-02-03T19:56:29Z")

</div>

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’].

---

<div class="post-metadata">

**Author:** ![jooma2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9bcb4/32.png) [@jooma2](https://www.ruby-forum.com/u/jooma2)\
**Post date:** [February 4, 2010, 12:21am UTC](https://www.ruby-forum.com/t/design-advice/182843/3 "2010-02-04T00:21:38Z")

</div>

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

> **[\#188 Declarative Authorization - RailsCasts](http://railscasts.com/episodes/188-declarative-authorization)**
>
> Short Ruby on Rails screencasts containing tips, tricks and tutorials. Great for both novice and experienced web developers.

---

<div class="post-metadata">

**Author:** ![jooma2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9bcb4/32.png) [@jooma2](https://www.ruby-forum.com/u/jooma2)\
**Post date:** [February 3, 2010, 9:02pm UTC](https://www.ruby-forum.com/t/design-advice/182843/4 "2010-02-03T21:02:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jooma2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e9bcb4/32.png) [@jooma2](https://www.ruby-forum.com/u/jooma2)\
**Post date:** [February 4, 2010, 10:56am UTC](https://www.ruby-forum.com/t/design-advice/182843/5 "2010-02-04T10:56:38Z")

</div>

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:  
> [#188 Declarative Authorization - RailsCasts](http://railscasts.com/episodes/188-declarative-authorization)

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.