Group Membership ANDing

Question

We're having difficulty designing a portal where users have
several diminsions (groups):
- User Department (e.g. HR, IT, Finance, Engineering)
- User Type/Role (e.g. contractor, employee, manager, etc)
- User Locations (e.g. Chicago, Seattle, Paris, Berlin, Tokyo)
How do I set it up, so that items can be set along these
dimensions? For example:
DeptGrp RoleGrp LocationGrp
UserA - Dept:HR, Role:Mgr, Location:Seattle
UserB - Dept:IT, Role:Emp, Location:Seattle
UserC - Dept:HR, Role:Emp, Location:Chicago
UserD - Dept:IT, Role:Emp, Location:Paris
So userA would belong to 3 groups: HR, Mgr, and Seattle, etc.
Now there are 3 items to publish:
Item1: For all people in HR dept.
Item2: For HR mgrs only.
Item3: For employees in the US only.
Can publish:
- item1 with group HR. This works!
- item2 with groups ???
***If use HR AND Mgr, then all people in either group can see them.
(Need people in intersection, not union of the groups).
- item3 with groups ???
***If use Employees AND Seattle AND Chicago groups, than all people
in any of the groups can see them (vs the intended audience).
Creating a HR_Mgr, HR_Emp, HR_Cont, etc group will not work,
as there are 15 dep x 8 emp types x 20 locations = 2400 groups!!!!!
How do we design this properly? We were thinking of using
persepectives for the locations. (Category is already used
for DocType).
What is the recommendation on groups and user dept/role/location?

Answer 1

We're facing the same problem and have made similair posts to the forum. I've been told it's a common problem in domain user management as well. If we're dealing with a dynamic page, we've let the page do some dynamic determinations, but with folder items, you're stuck to a group-based permission.
The best we've been able to do was to create a form to make it easier for publishers to make groups from the intersections of existing groups. There is a big drawback in that if a person (in your case) moves from one department to another, the "AND" groups you've created based on who was in the department would not be automatically updated. The best workaround we could develop was to develop another online utility for updating these "AND" groups. We've even gone so far as to consider building some triggers and procedures.
We're interested in a better solution.