Zend_ACL : How to design Role based ACL for multiple small teams?

How role based ACL should be designed for :

Multiple teams, each team consisting of one manager and multiple members and working from one location. Each location could have multiple teams and there are multiple locations.

Manager of each team could only view/edit data for his team members. A person could also be member of multiple teams, independent of location.

Location_1
-Team_1            -Team_2
 -Manager           -Manager
  -Me开发者_运维知识库mber_1          -Member_1
  -Member_2          -Member_2

Location_2
-Team_1            -Team_2
 -Manager           -Manager
  -Member_1          -Member_1
  -Member_2          -Member_2

My thought: I'm thinking of separating it in two parts. Part 1: There should be one group for each team. Maintain table of group membership in database. Part 2: Now, each user can have any role. And ACL could be designed based on those roles. But data would be fetched based on Part 1. this way new teams could be added without change in code. Is this a right way to go?

Kind of a fairly chatty answer here, loose discussion only, no code, at least for now.

Your own model/data structure has to consider members, locations, and teams. I think you have described the relationships pretty clearly, so that should be straightforward. Thinking relationally: a table for team members, including managers; a table for locations; a table for teams with a foreign key into locations and a foreign key into members identifying the manager; a cross-ref table linking members to teams. I assume your member model will have methods for isManagerOfTeam($team), isMemberOfTeam($team), stuff like that. Pretty straightforward.

But much of this is just modeling the relationships, arguably independent of access-control.

For access-control, it appears that location is irrelevant; it's team membership and team management that are the key.

It also sounds like the data you are trying to access-control (what will eventually be the 'resource') will be tagged with a member id, identifying the "owning" member. So, the model for that data might have a method getMember() or even just getMemberId().

So I see some Acl rules that use a Zend_Acl_Assert_Interface instance to make dynamic examinations on the relationships between the role ($member) and those resources:

1. My_Acl_Assertion_BelongsToSelf
2. My_Acl_Assertion_BelongToMemberUnderManagement

Then the assert() methods could call the relevant model methods on the passed role and resource to check the team and management relationships.

Like I said, kind of a loose answer, but hopes it helps with some ideas.