cancel
Showing results for 
Search instead for 
Did you mean: 

Granting rights programatically (through Jalo layer) ends up with inverted results

vladteodorescu
Explorer
0 Kudos

Hello everybody,

I'm trying to set up the permissions for a certain user group on certain types (or attributes thereof). I have written myself a custom hook that does this when updating the running system, calling, for each type/attribute obj to be updated, the following function:

 protected void grant(Item obj, Principal target, int permissionMask) throws JaloSecurityException
     {
         final AccessManager accessManager = AccessManager.getInstance();
 
         final boolean isAttribute = (obj instanceof AttributeDescriptor);
         List<UserRight> allRightsList = isAttribute ?   accessManager.getDescriptorUserRights() :
                                                         accessManager.getTypeUserRights();
 
         List<UserRight> rights = new ArrayList<UserRight>();
 
         rights.add(allRightsList.get(accessManager.getRightIndex(AccessManager.READ)));
         rights.add(allRightsList.get(accessManager.getRightIndex(AccessManager.CHANGE)));
         if (!isAttribute) {
             rights.add(allRightsList.get(accessManager.getRightIndex(AccessManager.CREATE)));
             rights.add(allRightsList.get(accessManager.getRightIndex(AccessManager.REMOVE)));
         }
 
 
         List<Boolean> permissionList = new ArrayList<Boolean>(rights.size());
         Map<Principal, List<Boolean>> rightsMap = new HashMap<Principal, List<Boolean>>(1);
 
         for (int i = 0; i < rights.size(); i++)
         {
             if ((permissionMask & (1 << i)) > 0)
                 permissionList.add(Boolean.TRUE);
             else
                 permissionList.add(Boolean.FALSE);
         }
 
         rightsMap.put(target, permissionList);
 
         obj.setPermissionsByMap(rights, rightsMap);
     }


Everything works pretty nicely, except for the fact that the rights for target on obj are set reversed. I.e, rights granted programatically are shown as "forbidden" in the hMC, while rights that are programatically removed are shown in the hMC as "granted". Now, the obvious solution is to revert the boolean values passed to the permissionList.add() functions, but I'm wondering if there is a reason why hybris behaves as it does.

Best regards, Vlad

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

If you look at /platform/ext/core/testsrc/de/hybris/platform/test/SecurityTest.java you actually find the same behavior:

     settings = new HashMap();
     settings.put(p, Arrays.asList(new Object[] { Boolean.TRUE, Boolean.FALSE }));
     pkAtItem.setPermissionsByMap(Arrays.asList(new Object[]{ read, write }), settings);

     assertEquals(settings, pkAtItem.getPermissionMap(Arrays.asList(new Object[]{ read, write })));
     assertFalse(pkAtItem.checkTypePermission(p, read));
     assertTrue(pkAtItem.checkTypePermission(p, write));

"read" is set as TRUE and "write" is set as "FALSE", but the checkTypePermission checks the opposite.

Ah, JavaDoc says that it is that way: https://download.hybris.com/api/5.2.0/commercesuite/apidocs/de/hybris/platform/jalo/Item.html#setPer..., java.util.Map)

Changes permission settings for a given list of user rights. This is done by a map Principal -> [ Boolean.TRUE == negative || Boolean.FALSE == positive || null == not set }.

An example:

 rights = [ r1 , r2 , r3 ]

permissionMap = { user1 -> [ T , F , F ] user2 -> [ null, null, T ] } which means: user1 is denied r1, allowed r2 and r3 user2 is denied r3, others are not set ( default or derived permission is take )

Whyever one might implement it that way....

Answers (0)