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

[Shane Bryzak]

In this particular example, I see the Course instance as being the 
target of the permission check.  So if you want to check that you have 
permission to edit that course, the permission check would simply be:

s:hasPermission(courseHome.instance, 'edit')

If in addition to this you want to check that the user has permission to 
render the actual view, then you would use two permission checks:

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

Dan Allen wrote:
> 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
>>>
>>>
>>>       
>>     
>
>
>
>