Hi Les, Thanks for your input.
I agree that tying the permissions to UI constructs is a bad idea. In my situation though, it really maps to how the data model is structured (ie: to get a Task instance, I must first obtain a TaskList instance). Obviously, the UI reflects this also. Tree nodes are only accessible through their parent node. Furthermore, the use-case is to manage permissions at the leaf level (read the Task) and have the implementation imply whatever other permissions are required to handle this. POSIX file-system solved the issue by splitting the "read" permission in two: 'open' (x) vs. 'read contents' (r). 'cd' tests the 'open' permission while 'ls' tests the 'read contents' permission. If you don't have 'open' (x) on one of the parent paths, you can't reach the children, regardless of the rights you have on those. It's left to the user to set the 'x' on all parents (which is a huge pain, but completely understandable in a file-system context). So looking at the situation this way, it's really similar to my case: provide 'read' to a child implies 'open' on all parents. So in a TreePermission scheme, there would need to be some kind of distinction between reading a node and listing its children; similar to 'r' and 'x' in POSIX. Having a 'r' permission on a child could imply an 'x' permission on the parents. Sound reasonable? -- View this message in context: http://shiro-user.582556.n2.nabble.com/Question-regarding-WildcardPermission-tp5728829p5733532.html Sent from the Shiro User mailing list archive at Nabble.com.
