Pretty sure you can accomplish this with a Herald rule:

I think changing the proposed behavior (making subscribers inherited in some form) is possibly reasonable, in that this is probably a common desire, although it seems like users might also reasonably want to subscribe to /x/ without subscribing to /x/*. We could let you "subscribe (this page only)" vs "subscribe (this page and all sub-pages)" but Subscriptions would need to expand substantially to accommodate that and there are no other use cases in other applications that I can think of (except sort-of Projects).

We could make these different operations -- maybe make "Watch" a super-subscribe, like it is in Projects -- but Watch/Subscribe is currently incredibly confusing in Projects. Maybe there's a better term than "Watch" if we're going to have a general super-subscribe.

I don't think we should literally inherit the "Subscribers:" field. This makes it hard for users to manage their subscriptions (e.g., unsubscribing from /x/* requires you to go update a lot of pages to remove yourself), hard to add subscribers (e.g., adding a new subscriber to /x/* requires you to go edit every page), and generally cumbersome (e.g., "Subscribers: ..." appears on every sub-page).

@chad, I thought about that too, but this rule only comes into play after the page has been created. Since the view/edit permissions are inherited from the parent page, which has "Subscribers" access in this case, the form complains because without filled-in subscriber list, I "would no longer be able to view/edit the object". The form doesn't know about the Herald rule that makes this possible afterwards.

That sounds like a separate bug.

@epriestley, I agree that in many situations you might not want to auto-subscribe to sub-pages. However, I'm not certain that having "Subscribers" appear on every sub-page is a bad thing - it allows customization if the inherited default is inappropriate for a given page.

One idea would be an "inherited from parent" subscriber element (looks up subscribers from elsewhere, like project subscriptions).
Advantages:

• can remove myself in a single spot
• no need for a second field, can easily be replaced by a page-specific subscriber
• works well with @chad's Herald approach assuming the error message on submit can be fixed

Disadvantages:

• potentially difficult to indicate where the subscription comes from (maybe extra button "Unsubscribe from <particular parent page>" for every extra subscriber source?)
• can't specifically unsubscribe from just a single page without a special "-jpetso" negative subscriber element, or removing the inheriting subscription element altogether (which would likely affect other users)

In T9371#135913, @jpetso wrote:

@chad, I thought about that too, but this rule only comes into play after the page has been created. Since the view/edit permissions are inherited from the parent page, which has "Subscribers" access in this case, the form complains because without filled-in subscriber list, I "would no longer be able to view/edit the object". The form doesn't know about the Herald rule that makes this possible afterwards.

I'm trying to build a repro case here and failing. What specifically should I be doing? Are you creating a sub-page to a page you don't have access to?

Specifically, subscribers should have no affect on your ability to create a page, only policies.

The described behavior is working as expected, I think.

The key is that the parent has "View Policy: Subscribers", so the child is defaulting to this policy as well.

The author is not a subscriber by default, and does not have any special access to pages (authoring a page does not give you permanent access to it).

This is like setting "View Policy: Administrators" when you aren't an administrator, or "View Policy: No One". Neither of those policies are permissible because they would not allow you to view the page.

So the current solution would be: Create a project #board_members, #board_page_editors. Set /board/ view policy to #board_members, edit policy to #board_page_editors, and set up Global Herald rule to add #board_members as subscribers to any page with /board/ in the path?

Yeah, I think that's probably the cleanest way to approach this today. That mostly works around the management mess, too.