You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Jacques Le Roux (JIRA)" <ji...@apache.org> on 2008/12/20 12:10:44 UTC

[jira] Closed: (OFBIZ-2093) bug when adding new permissions to group

     [ https://issues.apache.org/jira/browse/OFBIZ-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Le Roux closed OFBIZ-2093.
----------------------------------

    Resolution: Fixed
      Assignee: Jacques Le Roux

Thanks Albert and Bruno,

I have applied your patch Bruno (as Albert suggested 1st) + the same fix for ProtectedViews in trunk revision 728266, R4 revision 728268.


> bug when adding new permissions to group
> ----------------------------------------
>
>                 Key: OFBIZ-2093
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2093
>             Project: OFBiz
>          Issue Type: Bug
>          Components: party
>    Affects Versions: SVN trunk, Release Branch 4.0
>            Reporter: Albert Mayo
>            Assignee: Jacques Le Roux
>            Priority: Minor
>             Fix For: SVN trunk, Release Branch 4.0
>
>         Attachments: newPermToGroupCache.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> *Problem*
> When I add a permission to a security group it will not be recognized immediately if the permission is already cached.  
> Example:
> 1. Log in with testuser to the order manager and it fails and caches the permission. 
> 2. Give the testuser the order manager view and OFBTOOLS_VIEW permissions and try to log in again. OFBiz will say the user still does not have permissions.
> *Reason:*
> I noticed the cache would update correctly when I take permissions away, but the cache wouldn't clear when I added new permissions.  The addSecurityPermissionToSecurityGroup service (securityext/script/org/ofbiz/securityext/securitygroup/SecurityGroupServices.xml) attempts to remove the cached security group permission but it fails to find the key. The key given for cache removal is newEntity, but after the newEntity is created it contains all the entity's values (like the createdStamp and createdTxStamp).   The cache key should only have the PK values.
> I still need to read the guidelines of contributing to the project, but below I put the fix I used on my ofbiz copy if someone wants to apply the fix sooner.
> *Fix:*
> Either you can call securityGroupPermissionCache.remove(newEntity) before the new <create-value value-name="newEntity"/> is called or you can make a lookupPKMap that only has the PK values and then use lookupPKMap to remove the permission cache.
> Here is what my new function looks like:
> {quote}
> <simple-method method-name="addSecurityPermissionToSecurityGroup" short-description="Add SecurityPermission To SecurityGroup">
>         <check-permission permission="SECURITY" action="_CREATE"><fail-message message="Security Error: to run addSecurityPermissionToSecurityGroup you must have the SECURITY_CREATE or SECURITY_ADMIN permission"/></check-permission>
>         <check-errors/>
>         <make-value value-name="newEntity" entity-name="SecurityGroupPermission"/>
>         <set-pk-fields map-name="parameters" value-name="newEntity"/>
>         <create-value value-name="newEntity"/>
>         
>         <!-- newEntity will have all SecurityGroupPermission values, so must create a PK entity for cache lookup to work -->
>         <make-value value-name="lookupPKMap" entity-name="SecurityGroupPermission"/>
>         <set-pk-fields map-name="parameters" value-name="lookupPKMap"/>
>         
>         <!-- clear the org.ofbiz.security.Security object's custom cache by newEntity -->
>         <call-bsh><![CDATA[ org.ofbiz.security.Security.securityGroupPermissionCache.remove(lookupPKMap); ]]></call-bsh>
> </simple-method>
> {quote}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.