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

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(a)jboss.com&gt; 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 >> >> >> >

Yeah, I see where you are coming from. It's definitely possible in the new model. It's just a different way of thinking about the problem. It's also simpler because one of the dimensions has been removed, which is likely a good thing. Regardless, we need to document this in seam21migration.txt and in the security chapter. I'll add a JIRA tomorrrow if you don't beat me to it. I will cite a couple of examples there so people understand the before and after picture. -Dan On Tue, Nov 11, 2008 at 1:37 AM, Shane Bryzak <shane.bryzak(a)jboss.com&gt; wrote: > 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(a)jboss.com&gt; >> 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 >>>> >>>> >>>> >>>> >>> >> >> >> >