--- On Fri, 5/1/09, Andrew Zeneski <andrew.zene...@hotwaxmedia.com> wrote:
> After reviewing the Asset Maintenance component's method
> of overriding security, I understand the concern from Adrian
> in the other thread. This is something I left off the email
> below so I thought I would amend it now.
> 
> While this is a really creative workaround for the
> limitations in the current security implementation, it is by
> no means an ideal solution. It is even more logic spread out
> in even more places making understanding and customizing
> authorization even more cumbersome.
> 
> For these exact situations, the auto-grant functionality
> was implemented. So, instead of using ECAs to override
> permissions, you would define seed data (in the Asset Maint
> component, SFA, etc) which define which permissions are
> granted when a user is granted a specific application
> permission.

I read the Auto-Grant section. The question is, where is the seed data shown in 
your code example located? If it's it the SFA component, then the permissions 
are still spread around. All that has changed is instead of having 
permission-modifying SECAs in components, you have permission-modifying seed 
data in components. How was anything "centralized?"

I don't mean to pour cold water on your enthusiasm, it's just that I don't see 
where anything is being added or improved. It looks basically the same, only 
slightly different.

-Adrian



      

Reply via email to