On May 27, 6:34*am, "Kerry, Richard"
wrote:
> Would I be right in thinking that when wishing to use Groups for detailedaccess control it is neccessary to think in terms of creating one or more Groups for each Product. *Thus allowing there to be Read-only or Full control groups for each Product.
>
> This would suggest that I should consider Groups as being closely relatedto Products, rather than Users.
> I may have been thinking of "User Groups" when it may be better to think of "Permission Groups".


I would recommend both. If you've ever set up a network share on a
Windows NT 4.0 server, they are designed to be set up with Local
groups assigned to the share, and users assigned to the Global
Groups. Then the two groups are tied together by inheritance.

Same concept here. Instead of assigning permission groups to each
user, create user groups and separate product or permission groups,
then user groups inherit the permission groups. If you do it
backwards, everyone will have all permissions, so just make sure you
read and re-read the definition of "inherit", as I always forget, and
find it difficult to explain via email, which direction is supposed to
inherit. Then just assign users to the correct groups.

Here we have 'site users', 'customer', 'developers', and 'builds and
controls' for user groups. Then I have read groups, enter groups,
edit groups, and manage groups for each product, and they build on
each other like a pyramid. Anyone with Manage automatically (via
inheritance) gets edit permissions for a product, and anyone with edit
gets enter, and anyone with enter gets read. Then we just assign the
user group to the highest level of permission that they need, and they
automatically get everything else. Someone complicated and over
engineered, but that is the way we do things. :-) Saves me from
having to explain it too many times to new people coming to the team.