Update to Confluence Content Restrictions V1 API behavior for read and update operations

Rollout: progressive rollout by tenant IN PROGRESS

What's changing We are updating the behavior of the Confluence Cloud REST API V1 content restrictions endpoints to ensure consistency between view and edit access. Previously, it was possible for a principal (user or group) to hold an update (Can edit) restriction without holding the corresponding read (Can view) restriction on content that had view restrictions applied.

After this change, for content with view restrictions:

• All principals will hold either only the read restriction (Can view) or both the read and update restrictions (Can edit).
• If a principal holds both read and update restrictions, any API request to remove only the read restriction (but not all read restrictions) will result in a rejection.
• To move content into an "edit restricted" state for these principals, you must request the removal of all read restrictions.

What you need to do If your application manages content restrictions via the Confluence Cloud REST API V1, review your implementation to ensure that content with view restrictions:

1. When granting update access, you also include the read restriction for that principal.
2. Your logic for removing restrictions accounts for the fact that read access is now a prerequisite for update access.