authorized button enablement

Jay Shaughnessy jshaughn at redhat.com
Fri Apr 8 18:14:31 UTC 2011


Makes sense, I just wanted folks to know it was there if it was useful 
for them.

As an aside, it may be useful at times to pass in an EntityContext in 
some of these Abstract classes, to facilitate some ability to write 
conditional code when it makes sense.  That approach worked out well in 
some recent portlet work, enabling some succinct coding.

On 4/8/2011 12:56 PM, Ian Springer wrote:
> s/MANAGE_SETTINGS resource perm/MANAGE_SETTINGS global perm/
>
> On 04/08/2011 12:35 PM, Ian Springer wrote:
>> My changes were in AbstractAlertDefinitionsView, which is the base class
>> for resource, group, and template alertdef list views. Because the table
>> actions are created in this base class, it would be hard to use the
>> authorized table action classes, since the resource and group views
>> would have to use ResourceAuthorizedTableAction (for MANAGE_ALERTS
>> resource perm), but the template view would have to use
>> AuthorizedTableAction (for MANAGE_SETTINGS resource perm). So I'm going
>> to leave this one as if for now, since I think it will keep the code
>> more succinct. If there was a single AuthorizedTableAction that
>> supported both resource and group perms, then using it in this case
>> would make more sense.
>>
>> On 04/07/2011 09:15 AM, Jay Shaughnessy wrote:
>>> I saw a check-in yesterday that I think added some global authorized
>>> button enablement. I wanted to call attention to AuthorizedTableAction
>>> and ResourceAuthorizedTableAction, which may help out when dealing
>>> with button enablement and permission checks.
>>>
>>> Jay
>


More information about the rhq-devel mailing list