[seam-dev] lost functionality in rule-based permission checks

[Dan Allen]

Hmmm.

Okay, let's go with the example. Let's say that I am going to edit a
record. In this case, the name of the permission check would be the
view ID, something like /CourseEditor.xhtml. The action would be
'render' since this is happening before the page is rendered (though I
would likely have one for 'restore' too). Finally, we need to consider
the record which is being edited.

s:hasPermission('/CourseEditor.xhtml', 'render', courseHome.instance)

Now, I guess it would be possible to transpose this call into the Seam
2.1 model as follows

s:hasPermission(null, '/CourseEditor.xhtml:render', courseHome.instance)

It's a bit odd that the name and context object are being swapped
inside the method because it makes for an awkward placement of null in
this case.

I'm not convinced that everything is solved, but I can tell you that
we are going to need to document the migration. For people who have a
lot of rules in 2.0, they may have to do a fair amount of transposing
to make them fit in 2.1.

-Dan

On Tue, Nov 11, 2008 at 1:10 AM, Shane Bryzak <shane.bryzak at jboss.com> wrote:
> Unfortunately that would break the PermissionResolver interface, and the
> meaning of what a Permission is has been well defined in Seam 2.1.0 (for the
> better).  Can you give me an example of one of these permission checks and
> the corresponding rule?
>
> Dan Allen wrote:
>>
>> Shane,
>>
>> It appears that when the migration was made to the chain of permission
>> resolvers in Seam 2.1, the ability to place arbitrary objects into the
>> Drools working memory was lost. Before Seam 2.1, a permission check
>> consisted of a name, an action, and an unbounded set of contextual
>> objects. In Seam 2.1, only the first optional argument is considered,
>> and it's inserted into the working memory in place of the name.
>>
>> public boolean hasPermission(String name, String action, Object...arg)
>> {
>>   ...
>>   if (arg != null)
>>   {
>>      return permissionMapper.resolvePermission(arg[0], action);
>>   }
>>   else
>>   {
>>      return permissionMapper.resolvePermission(name, action);
>>   }
>> }
>>
>> I have quite a number of rules that rely on both the name and the
>> extra parameters. I'm sure others do as well. Can we change this logic
>> so that the permission mapper preserves the ordering of arguments and
>> the RuleBasedPermissionMapper stuffs the optional arguments into the
>> working memory?
>>
>> -Dan
>>
>>
>
>



-- 
Dan Allen
Software consultant | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.