When deleting resource actions and adding new ones, the new ones do not get assigned the correct bitwise values, rendering it impossible to add new resource actions if you have ever had more than 64

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.2.X EE, 7.0.1 CE GA2
• Fix Version/s: 7.0.0 DXP SP1, 7.0.3 CE GA4, 7.0.0 DXP FP33, 7.0.0 DXP SP7, 7.0.5 CE GA6, Master
• Component/s: Application Security > Permissions
• Labels:
  • liferay-digital-enterprise-70-sp1
  • liferay-digital-enterprise-70-sp7
  • liferay-fixpack-de-2-7010
  • liferay-fixpack-de-33-7010
• Branch Version/s:
  7.0.x
• Backported to Branch:
  Committed
• Story Points: 1.25
• Fix Priority: 3
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/52285

Description: The maximum number of resource actions supported for a given resource is 64. However, if the user has exceeded this limit and wants to remove some resource actions to make room for new ones, there is no obvious way to do this. Simply deploying an updated version of their war that removes some resource actions and adds in new ones causes strange behaviors with their resource actions. Calling the API to delete resource actions does not work, because when you try to deploy new resource actions afterward, they will not take the place of the old ones. Instead, they will all get the largest available bitwise value (-2^63).

LPS-49889 attempted to fix the issue of these weird behaviors by throwing an exception when you try to add more than 64 resource actions at a time. However, it is possible to circumvent this exception and still experience the weird behaviors, as I will demonstrate below.

Steps to Reproduce:

1. Deploy the attached permissions-test-portlet.
2. Check the resourceActions table of the database to ensure that all the permissions were added (there should be 64 entries for name=permissiontest_WAR_permissiontestportlet, with the last one being actionId PORTLET_29, bitwiseValue -9223372036854775808).
3. Run the following Groovy Script to delete some of the resource actions:

   import com.liferay.portal.kernel.service.ResourceActionLocalServiceUtil;
   
   String name = "permissiontest_WAR_permissiontestportlet";
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_01"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_02"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_03"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_04"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_05"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_06"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_07"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_08"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_09"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_10"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_11"));
   
   ResourceActionLocalServiceUtil.deleteResourceAction(
       ResourceActionLocalServiceUtil.fetchResourceAction(name, "PORTLET_12"));
   

4. Shut down the portal.
5. Download the attached permissions-test-portlet-modified and rename it to permissions-test-portlet. Place the portlet in the deploy folder. This is identical to the previous portlet except that the actionIds of some of the permissions were renamed.
6. Start the portal and wait for the new portlet to deploy.
7. Check your resourceActions table.

Expected result: The new resource actions would all be assigned distinct bitwise values, since other resource actions have been deleted to make space for them.
Actual result: The new resource actions have all been assigned bitwise values of -9223372036854775808, making them unusable.

Reproduced in master: b3a540167ec6cffb0030dacb5d65ea3029741106
Reproduced in 6.2.x: ea8d034b9afdc6b4b76dde47ac12f1eaa6ba65d6