Ancestor page permissions only are reported but other permissions may be enforced

Issue Summary

Page permissions are not enforced in the same way as suggested in the editor UI.

In particular, at https://github.com/wagtail/wagtail/blob/f0eef2fc88043ba627b89125876f1cfe53b7fc51/wagtail/admin/views/page_privacy.py#L16 and then https://github.com/wagtail/wagtail/blob/f0eef2fc88043ba627b89125876f1cfe53b7fc51/wagtail/admin/views/page_privacy.py#L52 the editor UI suggests that the first found ancestor restriction is the one which will be enforced, as it doesn’t show the permission configuration form if such a restriction is found.

However, it is possible to create a child page with higher permission than a private parent page.

Steps to Reproduce

Create two user groups. Foo and Bar, and a user in each, foo_user and bar_user.

Create two pages:

• /general-private-page/
• /general-private-page/foo-users-only-page/

First set a group permission on the second page for Foo group users only.

Only now set a group permission on the first page for Foo and Bar users.

Now foo_user can visit both pages, whereas bar_user can visit only /general-private-page/. However, in the editor, the privacy modal for /general-private-page/foo-users-only-page/ says:

This page has been made private by a parent page. You can edit the privacy settings on: General private page.

The privacy modal for /general-private-page/ shows that it is open to Foo group users and Bar group users.

I would expect either that bar_user can visit both pages, as suggested by the privacy modal, or that the admin show the child page permission form.

Technical details

• Wagtail version: 1.12.1

[alxbridge]

This is particularly an issue for intranet sites, where access to any page is restricted to authenticated users, and where you want access to subsections of the content to be restricted further (e.g. by group).

I agree with @nimasmi’s assessment that the desired behaviour is to allow the admin form to augment a page’s inherited permissions.

[nimasmi]

Discovering this came about from a use case where we wanted to be able to set extra restrictions on child pages, so personally the implementation is correct, but the admin form is wrong. Changing it the other way round (making the implementation match the admin’s reporting) would be a worse step, I think.