Asset Maintenance Permissions Problems
Locked
Asset Maintenance Permissions Problems
 
|
I noticed that the Asset Maint component requires the OFBTOOLS base permission to use the component.
So, I added that permission to a test user login. The Asset Maint component appears for that user login. When I try to perform any work, I get permissions errors because the Asset Maint component calls services in other components - which have their own sets of permissions. Updating a maintenance produced this error message: "Security Error: to run updateFixedAssetMaint you must have the ACCOUNTING_UPDATE or ACCOUNTING_ADMIN permission, or the limited ACCOUNTING_ROLE_UPDATE permission calling service updateFixedAssetMaint in updateFixedAssetMaintAndWorkEffort" The ACCOUNTING_ROLE_UPDATE permission doesn't exist. I added it manually to the test user login. After logging out and back in, I still get the same error message. I added the ACCOUNTING_UPDATE permission to the user login, and I was able to update a maintenance. Problem is, that gives me permission to update other things in Accounting.. This is the same type of problem I ran into with Forums - the Forum feature calls Content Manager services which require Content Manager permissions. I've suggested separating business logic from permissions checking logic in the past, but that got a mixed response. I could do that with the FixedAssetServices.xml file - move the embedded permissions checking to a separate service (using the new permissions checking capability). Any thoughts? -Adrian |
Re: Asset Maintenance Permissions Problems
|
|
Just define where alternate permissions are acceptable and add those cases to the permission checking services. The new permission-service stuff in the service engine (see the example entity for examples ;) ) makes this easier. You can extend the base permission service using ECA rules on the permission service used by the service you want to reuse. Just have it run your permission service after the main one IFF the main one results in an error (failed permission check), and make sure your ECA rule has it put its results in the context if your security scenario succeeds, and off you go... -David Adrian Crum wrote: > I noticed that the Asset Maint component requires the OFBTOOLS base > permission to use the component. So, I added that permission to a test > user login. The Asset Maint component appears for that user login. When > I try to perform any work, I get permissions errors because the Asset > Maint component calls services in other components - which have their > own sets of permissions. > > Updating a maintenance produced this error message: > > "Security Error: to run updateFixedAssetMaint you must have the > ACCOUNTING_UPDATE or ACCOUNTING_ADMIN permission, or the limited > ACCOUNTING_ROLE_UPDATE permission calling service updateFixedAssetMaint > in updateFixedAssetMaintAndWorkEffort" > > The ACCOUNTING_ROLE_UPDATE permission doesn't exist. I added it manually > to the test user login. After logging out and back in, I still get the > same error message. I added the ACCOUNTING_UPDATE permission to the user > login, and I was able to update a maintenance. Problem is, that gives me > permission to update other things in Accounting.. > > This is the same type of problem I ran into with Forums - the Forum > feature calls Content Manager services which require Content Manager > permissions. > > I've suggested separating business logic from permissions checking logic > in the past, but that got a mixed response. I could do that with the > FixedAssetServices.xml file - move the embedded permissions checking to > a separate service (using the new permissions checking capability). > > Any thoughts? > > -Adrian > |
Re: Asset Maintenance Permissions Problems
|
|
David E Jones wrote:
> > Just define where alternate permissions are acceptable and add those > cases to the permission checking services. > > The new permission-service stuff in the service engine (see the example > entity for examples ;) ) makes this easier. > > You can extend the base permission service using ECA rules on the > permission service used by the service you want to reuse. Just have it > run your permission service after the main one IFF the main one results > in an error (failed permission check), and make sure your ECA rule has > it put its results in the context if your security scenario succeeds, > and off you go... Wow - that's a great idea! I never thought of taking that approach. Thanks! |
|
|
In reply to this post by David E Jones
Interesting way to add an "OR(ed)" permissions set.
I suppose to add an "AND(ed)" permissions set (tightening constraints), we just do the ECA rule with "IFF main permissions set succeeds". Jonathon David E Jones wrote: > > Just define where alternate permissions are acceptable and add those > cases to the permission checking services. > > The new permission-service stuff in the service engine (see the example > entity for examples ;) ) makes this easier. > > You can extend the base permission service using ECA rules on the > permission service used by the service you want to reuse. Just have it > run your permission service after the main one IFF the main one results > in an error (failed permission check), and make sure your ECA rule has > it put its results in the context if your security scenario succeeds, > and off you go... > > -David > > > Adrian Crum wrote: >> I noticed that the Asset Maint component requires the OFBTOOLS base >> permission to use the component. So, I added that permission to a test >> user login. The Asset Maint component appears for that user login. >> When I try to perform any work, I get permissions errors because the >> Asset Maint component calls services in other components - which have >> their own sets of permissions. >> >> Updating a maintenance produced this error message: >> >> "Security Error: to run updateFixedAssetMaint you must have the >> ACCOUNTING_UPDATE or ACCOUNTING_ADMIN permission, or the limited >> ACCOUNTING_ROLE_UPDATE permission calling service >> updateFixedAssetMaint in updateFixedAssetMaintAndWorkEffort" >> >> The ACCOUNTING_ROLE_UPDATE permission doesn't exist. I added it >> manually to the test user login. After logging out and back in, I >> still get the same error message. I added the ACCOUNTING_UPDATE >> permission to the user login, and I was able to update a maintenance. >> Problem is, that gives me permission to update other things in >> Accounting.. >> >> This is the same type of problem I ran into with Forums - the Forum >> feature calls Content Manager services which require Content Manager >> permissions. >> >> I've suggested separating business logic from permissions checking >> logic in the past, but that got a mixed response. I could do that with >> the FixedAssetServices.xml file - move the embedded permissions >> checking to a separate service (using the new permissions checking >> capability). >> >> Any thoughts? >> >> -Adrian >> > > |
Re: Asset Maintenance Permissions Problems
|
|
In reply to this post by David E Jones
David,
I have the Fixed Asset permission checking extended as you described. It was incredibly easy. One problem though - when the user doesn't have the required permission, the fail message that is displayed is from the original service, not the one invoked by the ECA. Any ideas for that? -Adrian David E Jones wrote: > > Just define where alternate permissions are acceptable and add those > cases to the permission checking services. > > The new permission-service stuff in the service engine (see the example > entity for examples ;) ) makes this easier. > > You can extend the base permission service using ECA rules on the > permission service used by the service you want to reuse. Just have it > run your permission service after the main one IFF the main one results > in an error (failed permission check), and make sure your ECA rule has > it put its results in the context if your security scenario succeeds, > and off you go... > > -David > > > Adrian Crum wrote: > >> I noticed that the Asset Maint component requires the OFBTOOLS base >> permission to use the component. So, I added that permission to a test >> user login. The Asset Maint component appears for that user login. >> When I try to perform any work, I get permissions errors because the >> Asset Maint component calls services in other components - which have >> their own sets of permissions. >> >> Updating a maintenance produced this error message: >> >> "Security Error: to run updateFixedAssetMaint you must have the >> ACCOUNTING_UPDATE or ACCOUNTING_ADMIN permission, or the limited >> ACCOUNTING_ROLE_UPDATE permission calling service >> updateFixedAssetMaint in updateFixedAssetMaintAndWorkEffort" >> >> The ACCOUNTING_ROLE_UPDATE permission doesn't exist. I added it >> manually to the test user login. After logging out and back in, I >> still get the same error message. I added the ACCOUNTING_UPDATE >> permission to the user login, and I was able to update a maintenance. >> Problem is, that gives me permission to update other things in >> Accounting.. >> >> This is the same type of problem I ran into with Forums - the Forum >> feature calls Content Manager services which require Content Manager >> permissions. >> >> I've suggested separating business logic from permissions checking >> logic in the past, but that got a mixed response. I could do that with >> the FixedAssetServices.xml file - move the embedded permissions >> checking to a separate service (using the new permissions checking >> capability). >> >> Any thoughts? >> >> -Adrian >> > |
Re: Asset Maintenance Permissions Problems
|
|
Adrian Crum wrote: > One problem though - when the user doesn't have the required permission, > the fail message that is displayed is from the original service, not the > one invoked by the ECA. Any ideas for that? I haven't looked at how you implemented it, but if the ECA returns a message then it would be used. Chances are there is some niggly little detail to look into and play with for this to work. If you're having a hard time debugging this write up steps to reproduce and I or someone can take a look at it. -David |
Re: Asset Maintenance Permissions Problems
|
|
David,
https://issues.apache.org/jira/browse/OFBIZ-1236 -Adrian David E Jones wrote: > > Adrian Crum wrote: > >> One problem though - when the user doesn't have the required >> permission, the fail message that is displayed is from the original >> service, not the one invoked by the ECA. Any ideas for that? > > > I haven't looked at how you implemented it, but if the ECA returns a > message then it would be used. Chances are there is some niggly little > detail to look into and play with for this to work. If you're having a > hard time debugging this write up steps to reproduce and I or someone > can take a look at it. > > -David > > |
Re: Asset Maintenance Permissions Problems
|
|
I figured out the problem. The service dispatcher uses the result Map from the initial service
invoked and it ignores the result Map of any ECAs that are invoked. So, any values that an ECA service attempts to return are ignored. -Adrian Adrian Crum wrote: > David, > > https://issues.apache.org/jira/browse/OFBIZ-1236 > > -Adrian > > David E Jones wrote: > >> >> Adrian Crum wrote: >> >>> One problem though - when the user doesn't have the required >>> permission, the fail message that is displayed is from the original >>> service, not the one invoked by the ECA. Any ideas for that? >> >> >> >> I haven't looked at how you implemented it, but if the ECA returns a >> message then it would be used. Chances are there is some niggly little >> detail to look into and play with for this to work. If you're having a >> hard time debugging this write up steps to reproduce and I or someone >> can take a look at it. >> >> -David >> >> > |
Re: Asset Maintenance Permissions Problems
|
|
Are you using the result-to-context=true attribute on the action element of your eca def? -David Adrian Crum wrote: > I figured out the problem. The service dispatcher uses the result Map > from the initial service invoked and it ignores the result Map of any > ECAs that are invoked. So, any values that an ECA service attempts to > return are ignored. > > -Adrian > > Adrian Crum wrote: > >> David, >> >> https://issues.apache.org/jira/browse/OFBIZ-1236 >> >> -Adrian >> >> David E Jones wrote: >> >>> >>> Adrian Crum wrote: >>> >>>> One problem though - when the user doesn't have the required >>>> permission, the fail message that is displayed is from the original >>>> service, not the one invoked by the ECA. Any ideas for that? >>> >>> >>> >>> I haven't looked at how you implemented it, but if the ECA returns a >>> message then it would be used. Chances are there is some niggly >>> little detail to look into and play with for this to work. If you're >>> having a hard time debugging this write up steps to reproduce and I >>> or someone can take a look at it. >>> >>> -David >>> >>> >> |
Re: Asset Maintenance Permissions Problems
|
|
Yes, but that copies the result to the context, not to the result Map.
I just attached a patch to the Jira issue - take a look. David E Jones wrote: > > Are you using the result-to-context=true attribute on the action element > of your eca def? > > -David > > > Adrian Crum wrote: > >> I figured out the problem. The service dispatcher uses the result Map >> from the initial service invoked and it ignores the result Map of any >> ECAs that are invoked. So, any values that an ECA service attempts to >> return are ignored. >> >> -Adrian >> >> Adrian Crum wrote: >> >>> David, >>> >>> https://issues.apache.org/jira/browse/OFBIZ-1236 >>> >>> -Adrian >>> >>> David E Jones wrote: >>> >>>> >>>> Adrian Crum wrote: >>>> >>>>> One problem though - when the user doesn't have the required >>>>> permission, the fail message that is displayed is from the original >>>>> service, not the one invoked by the ECA. Any ideas for that? >>>> >>>> >>>> >>>> >>>> I haven't looked at how you implemented it, but if the ECA returns a >>>> message then it would be used. Chances are there is some niggly >>>> little detail to look into and play with for this to work. If you're >>>> having a hard time debugging this write up steps to reproduce and I >>>> or someone can take a look at it. >>>> >>>> -David >>>> >>>> >>> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |