3
votes

I'm making a small application to handle project related information and I'm having troubles with ACL. How do I best deal with the following situation?

My app has the following tables:

users: Keeps the users info (username, pass, email, group, etc)

groups: Groups where the users belong to. I have "administrators", "managers" and "registered"

roles: Roles for the registered users. I have "leader", "member" and "guest".

memberships: This table keeps the relationship between users, roles and projects.

projects: Keeps the projects info

items: Projects have several information items. This table keeps these items.

The tables have the following relationships:

users: hasMany Memberships, belongsTo Groups.

groups: hasMany Users

roles: hasMany Memberships

memberships: belongsTo Users, Projects, Roles

projects: hasMany Memberships, Items

items: belongsTo Projects

Basically managers (or administrators) can assign roles to registered users. Leaders and members can belong to several projects. Those belonging to a specific project can edit that project's data and its associated items. Leaders can assign members to a project from the pool of registered users.

Here is the situation in terms of CRUD:

Administrators: Full CRUD on everything (users, memberships, projects, items)

Managers: Can CRUD users of type "registered" but not "managers" or "administrators". Full CRUD on memberships, projects and items.

registered: Can do different things based on their roles:

leaders (role): Can update their own user info and read other user data that belong to their projects (info stored in the "memberships" table). Can CRUD memberships for their projects. Can CRUD items for their own projects. Can update their own projects.

members (role): Can update their own user info and read other user data that belong to their projects. Can CRUD items for their own projects. Can read memberships for their own projects. Can update their own projects.

guests (role): Can update their own user info. Can read projects.

Based on the above situation what do you think will be the best approach to deal with it? I tried with ACL but somewhere on the way I lost it. I tried playing with some of the ACL plugins available with no success. The biggest challenge is to deal with the permission creation by the managers and administrators. Please help!

I'm not yet an adept cake-baker so please be kind. Your suggestions and recommendation will be greatly appreciated. Thank you!

1

1 Answers

0
votes

Yes, Cake's ACL can be difficult. I can't give you a step-by-step explanation on how to solve your problem, but maybe I can help you with the big picture. I suggest you take a look Cake's sample ACL app docs -- maybe you only read the documentation on AclComponent? That part of the docs may be a little confusing.

I think you have to modify your database structure a little, to make it "the ACL way":

  1. Instead of the roles table, use nested groups (put a parent_id column on table groups).
  2. You also don't need the membership table. ACL has the aros_acos table for that.
  3. You manage Groups as AROs. Your Controllers for projects and items (or specific actions on those controllers) are the ACOs.
  4. If you setup ACL properly (check this), the user management Controllers and Models (User, Group, UsersController, GroupsController) "magically" take care of maintaining the aros table.
  5. Unfortunately it's not so simple with ACOs and the acos table. You have to decide how to manage those (see here and the section after that).
  6. On your AppController::beforeFilter method, you use the allow and deny methods of the ACL Component to grant or deny access to the current Controller/action ($this->name, $this->action)

I believe you are almost there, tt should not be complicated once you get used to Cake's ACLs.