views:

96

answers:

2

I began writing an app using declarative_authorization (http://github.com/stffn/declarative%5Fauthorization) but I'm now wondering if it's the correct approach.

In my app, I was giving some Users a "customer" role, some an "administrator" role, and some a "superadmin" role. That was working fine, but I now realise that I need some fields on the models which are specific to the "customer"

Superadmin = administrator editor

Admin = customer editor

Customer = has extra attributes like "avatar"

At this point I began creating a Customer model which inherited from User. However in that case, Customers would always have the "customer" role and only customers would have that role. That seemed a bit strange.

I guess I'm looking for a bit of guidance for this scenario.

A: 

Could you further elaborate on the emergent differences between the administrator and user roles?

Edit per your update: Personally I don't think a customer role is necessary per se, unless there is a lesser privileged category of authenticated user. I would just require a logged in user for any actions you wouldn't want a guest to perform, and require admin/superuser roles for any actions you didn't want regular users to perform. I think that getting into multiple models or even STI is unnecessary.

If there is a special case specific to your app that I'm missing out on, please let me know! ;)

Steve Graham
You're suggesting that maybe an administrator is just a standard user? In the real app, there's actually a third level - a superadmin, which is allowed to edit administrators. Superadmin = administrator editorAdmin = customer editorCustomer = has extra attributes like "avatar"
colinramsay
Edited the original question to include this information.
colinramsay
A: 

I rolled my own solution to this which I detailed in http://colinramsay.co.uk/diary/2010/02/24/rails-has_one-am-i-missing-something/

colinramsay