Symptoms

User specific page restrictions are removed after upgrade to Confluence 5.2.4.

For example, you have restricted a page to a user and after the upgrade anyone who has page view permission for that space is able to see the previously restricted page and any child pages.

If the following appears in the atlassian-confluence.log from the upgrade then you have most likely been affected:

[atlassian.confluence.upgrade.UpgradeTask] removeDuplicates Found 315 redundant duplicates in the [USERNAME] column of the [CONTENT_PERM] table; deleting them
[atlassian.confluence.upgrade.UpgradeTask] deleteRows Deleted 315 rows out of 315 in CONTENT_PERM table

Cause

We have discovered an issue where user specific page restrictions are removed completely during the upgrade to 5.2.4. 

This bug only affects customers who upgraded directly from version 5.1.5 or earlier to 5.2.4.

PLEASE NOTE: Customers who upgraded from 5.2.3 to 5.2.4 are NOT affected by this bug.

Refer to  CONF-30749 - Getting issue details... STATUS  to follow the progress of this issue. 

Resolution

If you have upgraded from 5.1.5 or earlier to 5.2.4 you should:

• Revert your upgrade of Confluence to the previous version by installing the previous version and restoring the database and home directory - see How to rollback to a previous version for more information.

If you need any further assistance please contact Atlassian Support.

If there has been too much activity for you to consider a rollback, and you do have a database backup from prior to the upgrade then there is a plugin available (attached to this page) to restore the page restrictions from the backup.

You must backup your production database before you begin this operation.

select c.CONTENTID, c.TITLE, s.SPACEKEY, s.SPACENAME, cps.CONT_PERM_TYPE
from CONTENT c
right join CONTENT_PERM_SET cps
on cps.CONTENT_ID = c.CONTENTID
left join SPACES s
on c.SPACEID = s.SPACEID
where cps.LASTMODDATE > 'date of backup YYYY-MM-DD e.g. 2013-09-11';

 contentid |                    title                    | spacekey | spacename | cont_perm_type
-----------+---------------------------------------------+----------+-----------+----------------
   1015819 | Page With View Restrictions Only 1          | TEST     | Test      | View
   1015821 | Page With View Restrictions Only 2          | TEST     | Test      | View
   1015815 | Page With Restrictions 1                    | TEST     | Test      | Edit
   1015815 | Page With Restrictions 1                    | TEST     | Test      | View
   1015817 | Page With Edit Restrictions Only 1          | TEST     | Test      | Edit
   1015823 | Page with one edit and one view restriction | TEST     | Test      | View
   1015823 | Page with one edit and one view restriction | TEST     | Test      | Edit
(7 rows)

1. Install the content-restrict-1.8.jar plugin into your running 5.2.4 instance, by going to Admin > Manage Add-ons > Upload an add-on manually. 
   • If you have problems with this, you made need to use the legacy plugin manager which can be accessed at http://<server>/<context>/admin/plugins.action
 
2. Restore your backup DB dump to a new database/tablespace. Ideally this would be a separate non production DB server, to minimise the risk of any mistakes during the restore process.
    
3. Get the hibernate.connection.url property from your confluence.cfg.xml file and modify it to point to the backup database you have just created.
   • This property will look something like jdbc:mysql://localhost/dbname
 
4. In your running 5.2.4 instance go to the admin console and click the 'Content Restrict Migrator' link.
    
5. Complete the form presented to point the plugin at your restored back up database -
   
   
   

6. On completion you should see a report something like this - 

   Found 23 user content permissions. Inserting them to destination database...
   Finished migrating 17 user content permissions.
   Queuing affected content objects for re-indexing...
   Finished queueing 6 content objects for re-indexing.

   Do not worry if the number of content permissions migrated does not match the number found. The new system will ignore any duplicates, which is the cause of any discrepancy in the numbers. Check your pages and make sure you are comfortable that the restore was successful.

7.  Uninstall the plugin from your system. It is not intended to remain available beyond it's purpose.
    
8. The final step is to rebuild your index. This is described in more detail here.

If you do not have a pre-upgrade backup from which to restore restrictions

You must backup your production database before you begin this operation.

The content-restrict-1.8.jar can be used to report on the potential set of affected pages and can also automatically add group restrictions to those pages. Either the same restriction to all pages or a different group restriction per space.

1. Install the content-restrict-1.8.jar plugin into your running 5.2.4 instance, by going to Admin > Manage Add-ons > Upload an add-on manually. 
   • If you have problems with this, you made need to use the legacy plugin manager which can be accessed at http://<server>/<context>/admin/plugins.action
 
2. In your running 5.2.4 instance go to the admin console and click the 'Content Restriction Migrator' link.
    
3. You will be shown a report similar to this -
   
   This report is showing a break down of all the pages which should have content restrictions, separated by space. The lozenge showing 'POTENTIAL ISSUE' indicates that the page may have had a restriction removed. The lozenge is only reporting a 'potential' problem. You can either manually check and confirm the page has the permissions it should, or you can perform bulk restrictions to a new group as described next. 
    
4. There are two operations you can perform from this screen.
   1. For each space, bulk apply a new restriction to a group you specify in the 'Restrict to group' text box. 
   2. For all pages across all spaces apply a restriction to a group you specify.
   After the page title you see the restriction types listed e.g. [View, Edit]. The new restrictions being created will be as specified by this list.
   So if the page with the 'POTENTIAL ISSUE' only used to have 'Edit' restrictions then only a new 'Edit' restriction will be applied.
    
5. After clicking 'Restrict' you will either see the result message "All the selected pages have been successfully restricted to the specified group". If the group permission being applied already existed on some of the pages being operated on then you may see a report like this:
   
   
   
   You should manually review that each of these pages have the restrictions you expect.
    
6. You are now finished and all the pages you choose should have the correct group restriction types applied. Re-running the report will show a result like:
   
   
   The pages which still show ''POTENTIAL ISSUE' are simply the ones where the group restriction you were trying to create already applied and so the plugin took no action on those pages.
   
   
7. All pages with content permissions on your site are now restricted to the groups you have specified.
    
8.  Uninstall the plugin from your system. It is not intended to remain available beyond it's purpose.

Please watch this page for further updates and steps.