gmane.comp.lang.ruby.rails

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.

--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Marcelo de Moraes Serpa | 20 Jul 21:10

Re: Designing a user system: Groups or STI ?

No one ever stumbled upon this design issue?

On Fri, Jul 18, 2008 at 12:23 PM, Marcelo de Moraes Serpa <celoserpa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

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.

headers

Erik Rantapaa | 21 Jul 08:14

Re: Designing a user system: Groups or STI ?


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

-- 
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@...
To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

headers

Marcelo de Moraes Serpa | 24 Jul 19:00

Re: Designing a user system: Groups or STI ?

Thanks Eric,

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

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 Rantapaa <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:

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.
--
Posted via http://www.ruby-forum.com/.