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:
- My_Acl_Assertion_BelongsToSelf
- 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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…