Designing a user system: Groups or STI?

Hello list,

This is more of a architectural question and I hope someone out there
could
enlighten me.

I’m starting the object model of my current project, and I can see that
there will be various kinds of users, such as:

  • Clients
  • Photographers
  • Suppliers
  • Member

I would usually just add the semantic and categorization using a n:n
relationship with a Group entity. However, I also detected that some of
these “user kinds” might have additional attributes and business logic
tied
to them. For example, a Photographer will have a field of “cameras” that
could even be a has_many relationship with a Camera entity. This could
not
be done with a Group alone.

I can see that both approaches, Group and STI allow you to:

  • Categorize and control permission.
  • Identify a user semantically in code and perform code depending on
    the
    “kind/group” of the user.

But STI is has some advantages if you want additional attributes and
logic
tied to the subtype model.

Group is nice to manage permissions and they can be changed, created and
assigned to a user at runtime, something STI can’t do since it requires
a
ruby class in the filesystem.

I’m kind of confused on how I solve this issue, if someone has some tip
or
design principles to help me here, I would be really grateful!

Thanks,

Marcelo.

No one ever stumbled upon this design issue?

On Fri, Jul 18, 2008 at 12:23 PM, Marcelo de Moraes S. <

This is just a thought, but you might be trying to do too much with STI.

If Groups work well for authorization, then use Groups for
authorization.
(btw, this approach sounds a lot like RBAC where a Group is like a
“role” in RBAC)

If STI works well for (whatever), use STI for that.

This means that you will have to keep the two in sync, but you should
also get
the benefits of both as well.

Thanks Eric,

Yes, I was talking about RBAC, I just didn’t know the term at the time
:slight_smile:

Actually I think I can reformulate my original question as: “Is using
STI to
create subtypes of Users for access control a good practice/pattern?”

I’ve been asking this question in #rubyonrails, and found out that most
people don’t use STI in the User model for access control. I think it
could
work for small applications, but bigger applications need something that
can
be managed at runtime, i.e: roles of users can be changed at runtime.
With
STI, your “roles” (subclasses of the User model class) aren’t made for
being
switched at runtime. Of course, you can change the type attribute, but
that
is awkward at its best, and creating new “roles” involves creating new
classes at the filesystem.

STI works well for other more static elements, but for access control,
hmm,
I don’t think so. I don’t think a User model should have subclasses.

Thanks,

Marcelo.

On Mon, Jul 21, 2008 at 3:14 AM, Erik R. <