Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-12911

Pages that inherit page restrictions are not respecting those restrictions after upgrade to Confluence 2.9

XMLWordPrintable

      Tested and verified in both customer enviornment and in test enviornment.

      In the event that you have a parent page restriction and a child page that inherits that restriction, upon upgrade, 2.9 will only respect the explicit parent permission in terms of security trims and actual access but not respect inherited child permissions. This only affects permissions that were in place prior to upgrade. New restrictions placed upon pages work fine.

      When editing pages that are inheriting page restrictions, the page restrictions are shown to be in place, though the actual restrictions are not respected.

            [CONFSERVER-12911] Pages that inherit page restrictions are not respecting those restrictions after upgrade to Confluence 2.9

            Andrew Lynch (Inactive) added a comment -

            Merged to trunk.

            Andrew Lynch (Inactive) added a comment - Merged to trunk.

            m@ (Inactive) added a comment -

            This has been done for 2.9.1, just need to merge it to trunk.

            m@ (Inactive) added a comment - This has been done for 2.9.1, just need to merge it to trunk.

            Paul Curren added a comment - - edited

            The manual fix for affected users is very straightforward. As an administrator visit the URL -

            http://<confluence address>/admin/permissions/pagepermsadmin.action

            This page contains a single buttons called Rebuild Ancestor Table. Click this to rebuild the ancestor relationships for the Confluence content. Depending on the size of your Confluence instance, this task could take 10 minutes or more to complete.

            The final step is to flush the Inherited Content Permissons cache so that the rebuilt permissions are picked up.
            Instructions for flushing caches can be found here on CAC.

            Paul Curren added a comment - - edited The manual fix for affected users is very straightforward. As an administrator visit the URL - http://<confluence address>/admin/permissions/pagepermsadmin.action This page contains a single buttons called Rebuild Ancestor Table . Click this to rebuild the ancestor relationships for the Confluence content. Depending on the size of your Confluence instance, this task could take 10 minutes or more to complete. The final step is to flush the Inherited Content Permissons cache so that the rebuilt permissions are picked up. Instructions for flushing caches can be found here on CAC .

            Paul Curren added a comment -

            Also, we'll need an upgrade task to fix this for people who have already went to 2.9.
            The quick and easy way to do this is to bump the build number in the RebuildAncestorsUpgradeTask and make sure the task is wrapped by the upgradeTransactionProxyCreator.

            Paul Curren added a comment - Also, we'll need an upgrade task to fix this for people who have already went to 2.9. The quick and easy way to do this is to bump the build number in the RebuildAncestorsUpgradeTask and make sure the task is wrapped by the upgradeTransactionProxyCreator .

            Paul Curren added a comment -

            The RebuildAncestorsUpgradeTask makes use of an old class called AncestorTableBuilder.
            This AncestorTableBuilder is pretty mixed up in it's database interactions.
            It first removes the current contents of the CONFANCESTORS table and then explicitly commits the session Connection.

            It then attempts to do it's rebuilding of this table using HQL and Hibernate sessions. However it doesn't then explicitly commit these subsequent database operations.

            So the end result is that unless the AncestorTableBuilder has been wrapped in a transaction (e.g. used in an action or an upgrade task that is wrapped in a transaction) you will end up with an empty CONFANCESTORS table and visible pages that should have been protected.

            A very quick and easy fix would be to ensure that the RebuildAncestorsUpgradeTask is included in the upgradeTransactionProxyCreator configuration in upgradeSubsystemContext.xml. However it would be better to fix the class.

            Paul Curren added a comment - The RebuildAncestorsUpgradeTask makes use of an old class called AncestorTableBuilder . This AncestorTableBuilder is pretty mixed up in it's database interactions. It first removes the current contents of the CONFANCESTORS table and then explicitly commits the session Connection. It then attempts to do it's rebuilding of this table using HQL and Hibernate sessions. However it doesn't then explicitly commit these subsequent database operations. So the end result is that unless the AncestorTableBuilder has been wrapped in a transaction (e.g. used in an action or an upgrade task that is wrapped in a transaction) you will end up with an empty CONFANCESTORS table and visible pages that should have been protected. A very quick and easy fix would be to ensure that the RebuildAncestorsUpgradeTask is included in the upgradeTransactionProxyCreator configuration in upgradeSubsystemContext.xml . However it would be better to fix the class.

            Tim Wong (Inactive) added a comment -

            CSP-22887 is the original support ticket.

            Tim Wong (Inactive) added a comment - CSP-22887 is the original support ticket.

              mjensen m@ (Inactive)
              13bf5b92ed59 Michael Twohey
              Affected customers:
              1 This affects my team
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: