>> Well, actually, nobody but the assigned reviewer is allowed. >> As I will have the field around for DB queries anyway, I guess that >> permissions don't add value from the app logic point of view. > > Well, that depends on your app logic ;)
Point taken. :-) Actually, I don't mind to have this logic around. The one thing I dislike though, is that I have to duplicate the code into the view of my web application to hide unavailable functionality from the UI. I hoped that with permissions it could turn out to a *simple* check. > In permission-based systems, Permissions describe raw application > functionality - they are the 'what' can be done in an application and have > no concept of 'who' can do something. Thanks for clarifying. I think I got that now. I'm only a little clumsy at using it. Although -- coming from the grails plugin -- I have to say that Peter's talk (w/ slides) made it a lot easier. > Similarly a Role is merely a named collection of Permissions. They aggregate > raw functionality into a 'bundle' of sorts that describes the ability to do > multiple things. There is still no 'who' at this level. > > The users are the 'who'. 'Who' can do 'what' is usually achieved by > assigning one or more roles to a user, for example, > user.getRoles().add(aRole); > > If you have a dynamic role system, where you can add/delete roles at > runtime, your application code _must_ check against permissions, not roles. That much was clear. Thanks for the explanation and patience :-) Cheers, DJ
