Anil Patel wrote:
>> Part of the point (if I remember right) of putting permission logic
>> into little services was to help keep it consistent when that service
>> is called in multiple places, especially in the input processing
>> service and the output generating screen.
> How is writing "acctgI
Don't need to actually respond to any particular thing David said,
just reusing his change of subject for my email.
==
PermissionNameOrPattern Command Action Roles
--- --- -- -
/Path/To/Resource UPDATE ALLOW \
(FOO_ADMIN|FOO_UPDATE)&FOO_TRAINED
/P
On May 3, 2009, at 1:36 PM, David E Jones wrote:
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- On Sat, 5/2/09, David E Jones
wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexible, for
On May 3, 2009, at 2:43 PM, Anil Patel wrote:
Inline.
On May 3, 2009, at 1:36 PM, David E Jones wrote:
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- On Sat, 5/2/09, David E Jones
wrote:
My personal opinion on this is that the design has only
subjective improvements and most of i
Inline.
On May 3, 2009, at 1:36 PM, David E Jones wrote:
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- On Sat, 5/2/09, David E Jones
wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexib
Just for clarification, my proposal did include a new way to write
permissions using groovy, but it also supports permissions as services
ad well as a new interface to implement very common permission
checking routines for re-usability.
This was only one part of the proposal, the main focu
On May 3, 2009, at 4:57 AM, Adrian Crum wrote:
--- On Sat, 5/2/09, David E Jones wrote:
My personal opinion on this is that the design has only
subjective improvements and most of it is a big step
backwards (easier but less flexible, for the services versus
direct permission part anyway, and
