Using Users->Groups<-Permissions is definitely better for any system
with more than 100 users. I inherited a system (over 100 users)
where permissions were managed directly to users. It was very easy
and quick to fix/modify one Users permissions. However, we never
could find the time to rationalize the overall permissions as most
users with the same job requirements had over time evolved different
permissions. Why? We never knew for sure although we ended up
spending considerable time for each change trying to resolve
differences.
Using Users->Groups<-Permissions forces one to spend more time up-
front keeping permissions rationalized. Rational permissions may or
may not be important in a given installation. I agree with Jeff that
it should be the heavily favored option. It can be used for small
user communities without a lot of additional overhead (just a little
thinking beforehand). So I don't really see a downside.
Neil
On Feb 5, 2006, at 9:19 AM, Jeff Watkins wrote:
----
hi, i recently start to play with the identity frameworks from
turbogears and i really dont get the point of linking permission
to groups. if the 'write' permission is linked against the 'admin'
group, all users in admin group have write permission. if i need
diferente parmission for a specific user, i need to create another
group. so, what is the point? i really think that 'permissions'
should be linked against 'users'. this way the 'group' should say
which objects u can access and permission what u can do with given
objects.
There is nothing preventing you from creating a Model that better
suits your needs, however, experience with large user communities
shows that you're almost always better off modelling via Users-
>Groups<-Permissions rather than applying permissions directly to a
particular User.
If for no other reason, provisioning new users becomes a huge
problem. Consider the following example:
Sally, the nurse retires and her replacement Sam needs to be
provisioned in the new system. In an environment where permissions
are applied via groups, Sam is made a member of the Nurse group and
he immediately acquires *every* applicable permission. If
permissions are applied directly to the user, you need to
explicitly apply every permission in order to provision Sam.
Six months later, you role out new functionality for nurses. This
new functionality includes new permissions -- all nurses should
have these permissions. If you've modelled your users using groups,
you add the permissions to the nurses group and immediately every
nurse, including Sam, can now access the new functionality. If you
haven't modelled your data using groups, you need to add the
permissions to every single nurse. Now ask yourself, if you don't
have groups, how do you know who all the nurses are?
Now if you have a VERY small user community, applying permissions
directly to the user isn't a bad model. And I run into this a lot
with clients. Mostly when I encounter this model it's after they've
grown from a small number of users to many hundreds or even
thousands. In these cases, the permissions are often controlled by
different application specialists and no one quite knows what the
definitive set of permissions actually is for a given group or role.
