Modelling multiple types of users with Devise and Rails 4

Rails
#1

I have 3 types of “users”

Shop
Provider
Customer

The last 2 users will have similar attributes such as

First Name
Last Name
and so on

And the Shop user type will have the most contrast between types.

As far as behaviours they will all be quite different,
although Provider and Shop will inherent many of customer behaviours.

It seems the behaviours can be dealt with CanCan as I’ve researched.

I’m now attempting to how I should authenticate these types.

I have looked at the STI model but I couldn’t grasp where I would these
extra attributes.

My mental model is as follower:

User is a table and model
The types are abstract models that inherit from this.

So I’m wondering, how do I add attributes such as Business address for
just
the Shop type?

Or is it that the User Table has a column called Type and that type is
associated with these type tables? And within the type tables are the
extra
attributes?

#2

On Wednesday, 14 May 2014 11:21:49 UTC-4, Anthro Christian Ramsey wrote:

First Name

So I’m wondering, how do I add attributes such as Business address for
just the Shop type?

Or is it that the User Table has a column called Type and that type is
associated with these type tables? And within the type tables are the extra
attributes?

That would be “class table inheritance”. It’s not supported out of the
box,
but there may be a gem for it.

The “single-table inheritance” that ActiveRecord provides works off a
type column in the table, but all the fields are stored on the same
table. Some people object to the (possibly) large number of NULL columns
in
that case, YMMV.

One other thing to consider: in many of the applications I’ve worked on,
there’s a logical separation between two pieces that are somewhat mixed
together in the above:

  • “how users log in”: this is the various Devise plumbing (email /
    username, password, confirmation tokens, etc etc)

  • “information about a user”: this is everything else (address, etc)

It can be useful to split these into two classes (and two tables), say
“User” and “Profile”. This comes in especially handy when, for
instance,
a Shop owner requests that her assistant be able to administer the shop
as
well; this can be cleanly represented by Shop having many Users.

–Matt J.