Affects Version/s: 7.0.X EE, Master
Component/s: Core Infrastructure > Verify Extender
During the VerifyPermission process, a deleteDefaultPrivateLayoutPermissions method is run to delete all the guest permissions on private pages (both the pages themselves and portlet instances that exist on those pages). Back before
LPS-69907 was committed, this was a sensible thing to do. However, as of LPS-69907, we allow users to configure Guest permissions on private pages and on portlets on private pages as a way of setting the "default" permissions for those pages/portlets, since other users can inherit permissions from the Guest role. Therefore, we should no longer run this method in this verify process.
Steps to Reproduce
1. Start up the portal and log in as the admin user.
2. Create a new private page and go to its Configuration screen.
3. Click on the tri-dot button in the top-right corner, and click Permissions.
4. Assign a few permissions to the Guest role and click Save.
5. Stop the portal.
6. Add the following lines to portal-ext.properties:
7. Start up the portal again.
8. Visit the Permissions screen for your private page again.
Expected Result: The permissions that you assigned to the Guest role would still be there.
Actual Result: The permissions that you assigned to the Guest role have been removed.
Note: I had a thought that maybe we could run the deleteDefaultPrivateLayoutPermissions method iff permissions.check.guest.enabled=false. However, I feel weird about this since an administrator could hypothetically change their mind about the value of that property, and then find that all their guest permissions on private pages have been removed from the database when they reset permissions.check.guest.enabled to true.
Note 2: I didn't actually reproduce this issue in master using these steps, because there seems to be a bug inside of the isPrivateLayout method where if your primKey is not a long, the method will throw an exception which will be swallowed silently and cause the VerifyProcess to finish prematurely, never logging the error. So this issue may not actually be testable by QA as a result.