Thanks :-)
> I think having the concept of hierarchical security is important however thinking about this
> some more (I didn't address this either). For example, if you cant read somthing, then you
> can't edit it, because in order to edit, you need to be able to read.
That's the question... do we really want to implement/support such a hierarchical security system?
> What do you think is the best way to represent these logical constraints in the user
> interface? Maybe having a tree as opposed to a list?
>
>I've attached some screen shot of a 'enterprise' system which one of our clients has sent
> me - we may be able to draw on some ideas from here.
I think that's getting too complicated for most of the users. Not even for me it's obvious what happens when I check the root without trying it at least once :-)
Have I then all rights (also all child permissions) or just that (root-)permission?
I think that's just overkill!
If we really want to do things like "if you can’t read something, then you can't edit it, because in order to edit, you need to be able to read" we can do it as follows:
Define the permissions "Read" and "Read and Edit".
The read function can then simply OR the two permissions and the edit function just check the "Read and Edit" permission.
In that way it is immediately clear for the user what is meant with the permissions.
The only disadvantage that came in my mind is that there is some redundancy in the interface (if "Read and Edit" is enabled, "Read" has no effect anymore) but my opinion that isn't a big problem.
The people, who understand the system well, include just the needed permissions and for the others it makes no difference at all.