Complex Roles

8 views
Skip to first unread message
Message has been deleted

Jeremiah Messerer

unread,
Jan 13, 2010, 1:56:30 PM1/13/10
to acl9-discuss, derekb...@gmail.com
I am struggling with how to setup and use a complex series of roles
(in controllers and views), hopefully there is someone who has done
something similar and shed some light on the subject. I am NOT looking
for anyone to do it for me, just help me figure a few things out and
understand ACL9 usage.

The users and the activities are described below:
****************************************************************************************************************************************************************************************

Teachers, Teachers-Assistants, and Reviewers ALL belong to a School
System.
Students DO NOT belong to a School System AND can submit homework to
any assignment in any school system.

A review is a homework submission from a student to a teacher or
teachers-assistant for a particular assignment.
A reviewer would review (give a grade and a comment) each homework
submission from each student for a particular assignment that they are
assigned (assigned to an assignment within a school system).

System Administrator (SA)
This user can perform CRUD operations on any teacher, teachers-
assistant, and reviewer.
This user can perform CRUD operations on any assignment.
This user can perform CRUD operations on any review.
* Basically do anything in the system. *

Teacher (TEA)
This user can perform CRUD operations on teachers, teachers-
assistants, and reviewers in the same school system.
This user can perform CRUD operations on assignments in the same
school system.
This user can perform CRUD operations on reviews in the same
school system.

Teachers-Assistant (TA)
This user can perform CRUD operations on assignments (UD ONLY on
assignments they own).
This user can assign reviewers to assignments they own.
This user can perform CRUD operations on reviews pertaining to the
submissions from students to the assignments that the TA owns.

Reviewer (REV)
This user can perform R operations on an assignment.
This user can perform CRUD operations on reviews (UD ONLY on
reviews they own) pertaining to the assignments that they have been
assigned to by a TEA or TA.

Student (STU)
This user can create and submit submissions to any assignment in
any school system.

****************************************************************************************************************************************************************************************

Approach #1
---------------------------------------------------
My initial approach was to assign a single role (SA || TEA || TA ||
REV || STU) to a user.
If the created user is of type TEA, I would assign the TEA role.
If the created user is of type TA, I would assign the TA role.
If the created user is of type REV, I would assign the REV role.

I was uncomfortable with this because I found myself constantly using
a series of conditionals
(if current_user.has_role? "SA" || current_user.has_role? "TEA" ||
current_user.has_role? "TA") which seems to make several calls to the
database which seems like it could turn into excessive overhead and
reduce application scalability.

Approach #2
---------------------------------------------------
Currently, when a user is created in the system I am assigning roles
to that user (using .has_role! "ROLE"):
If the created user is of type TEA, I would assign TEA, TA, and REV
roles.
If the created user is of type TA, I would assign TA, and REV roles.
If the created user is of type REV, I would assign the REV role.

For example, if I wanted to see if a user could READ an assignment,
the lowest role assigned to users than can create assignments is
"REV". Thus, in my controller I would have some conditional logic "if
current_user.has_role? :rev", but in my view I am stuck with a series
of conditional logic to determine whether or not to display the "Edit"
or "Delete" links associated with that assignment. This seems to go
back to the concerns I had regarding approach #1.

---------------------------------------------------

Q1) Does this sound like the correct approach to assign multiple roles
(decreasing in "ability") to a single user (or is there another
approach I am not aware of)?
Q2) From what I gather (in documentation and discussion "Helpers and
testing authorization in views."(http://groups.google.com/group/acl9-
discuss/browse_thread/thread/bcf90867e5250f08)), I need to setup
access controls in the controller level to control the controller, but
I also need to setup similar controls in the helper so that I have
access to the methods in the helper in the view. Is that correct?
Q3) In the documentation (http://github.com/be9/acl9/), you mention a
"show_to" helper. What is required to get the "show_to" helper to work
in the view?
Q4) Is there anything that can be done to minimize database overhead
for role lookups or to make the conditional role lookups more
performant?

I appreciate any feedback and comments!

Thanks =~ Jeremiah

PS - Sorry for the long-windedness :-).

oleg dashevskii

unread,
Jan 16, 2010, 1:43:00 AM1/16/10
to acl9-d...@googlegroups.com, derekb...@gmail.com
Jeremiah,

you've got quite a complex system and I'm afraid stock acl9 will not suffice here.

I personally think that assigning multiple roles to one user is a bad idea. So there are two ways.

1. You implement your own has_role? / has_role! methods. Since total role count is limited (you mention 5 of them), a simple "role" column on the users table is enough. Though you'll also need to store relationships like teacher->school_system (this can be done with has_many :through and polymorphic join model).

2. You find a way to cache acl9 role requests.

As for Q2, one access_control block is enough. E.g. in the controller:

access_control :helper => :allow? do
   allow this
   deny that
end

Now in views you can use allow? helper.

<%= if allow?(:edit) %>
link_to 'Edit this thing', ...
<% end %>

Though this helper will work only inside the same controller.

To use show_to, you'll need to put include Acl9::Helpers inside your helper.

BTW, you might as well go with something like declarative_authorization, which presents a more systematic approach than acl9.

2010/1/14 Jeremiah Messerer <jmes...@gmail.com>



--
Oleg.
Reply all
Reply to author
Forward
0 new messages