Hi Chris, could you go a little more into your use case (I think what you've hinted at it with your Widget->add_comment block)? I believe the spirit of that Permission enum was to define the context of the security check to keep in line with CRUD actions. The detailed business logic of the Model/Permission Context combination can then be customized as needed in the various Default<Model>PagePermissionEvaluator.hasPermission functions. So if there is some specific security logic related to adding a comment to a widget, I believe you can put it in the appropriate PermissionEvaluator class.
Am I understanding your use case or completely off the mark? :) Tony >-----Original Message----- >From: Chris Geer [mailto:[email protected]] >Sent: Tuesday, October 02, 2012 7:50 PM >To: dev >Subject: [Proposal] Spring Permissions Change > >I would like to propose we change how the spring permission checks work >slightly. Right now the "Permission" value (i.e. Create, Update...) is >defined as part of a enum named Permission defined in >the org.apache.rave.portal.security.ModelPermissionEvaluator interface. The >various hasPermissions methods take an instance of that Permission enum >(created from a string on the check permission annotation). Having the >permissions defined in an enumeration limits what we are able to check >permissions for in my opinion. Right now we have two choices, 1) limit our >permission checks to the list there is now, 2) add new permissions to the >generic Permissions enum which could lead to a bunch of permissions stored >on a generic enum that aren't really reusable (i.e. Widget -> add_comment >permission). I would like to propose we change the way we define >permissions to remove the enum and just pass along the string defined in >the annotations. The only real downside of that is that we can't use a >switch/case statement during permissions checks unless we use Java7. > >Thoughts/concerns? > >Thanks, >Chris
