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