The way policy works is clearly understood, it's just impractical when you want to open up a bunch of wiki documents. This is impractical when you have a parent document and 20 children; yes I could go through and update the policies on all 21 documents, but it's annoying and tedious.

In our scenario it was that we wanted to add another project to the list of "members of projects" policy on who could view the deployment-related wiki articles. With custom policies, not only did I have to update all of the child documents, but I also had to go through the custom policy editor for each one.

I should add that the way Phragment currently solves this problem is that it has a "Replace policies on child fragments with the policies above.", but this seems less appropriate for Wiki articles (given that you might want to have a child document with a more restrictive policy than it's parent, whereas for Phragment you're usually updating policies for ZIP archives and all their files).

In T7140#96200, @hach-que wrote:

The way policy works is clearly understood, it's just impractical when you want to open up a bunch of wiki documents. This is impractical when you have a parent document and 20 children; yes I could go through and update the policies on all 21 documents, but it's annoying and tedious.

In our scenario it was that we wanted to add another project to the list of "members of projects" policy on who could view the deployment-related wiki articles. With custom policies, not only did I have to update all of the child documents, but I also had to go through the custom policy editor for each one.

Isn't this scenario typically...

• create parent doc with policy "people who deploy code"
• any sub docs created inherit this policy, unless of course some user changes things but lets assume they did that wisely
• ...then just add people to the project or create more sub docs as needed and everything is grand?

I do get how if you were to change the parent doc policy, say by adding another project with something like "people who also deploy code but can't be in the main code deploy project", that could be annoying. That said, it feels like once organizational churn simmers down this should be definable in a scalable way?

Basically, this all seems to be the right balance of complexity and power to me. Or said differently, I am not concerned with folks trying to make a set of documents more open having to jump through a hoop or two and carefully think through policy for the future, etc. (If we just took the solution as you proposed it, we'd have the issue of child documents accidentally becoming more open which strikes me as wildly dangerous versus just a hassle...)

In our scenario, we have members of various teams who can control deployments, as well as the DevOps team (all of who can control deployments). We could create another project which is "DevOps + Deployment Managers", in addition to the "DevOps" and "Deployment Managers" projects, but this seems like more maintainance of projects (what happens if someone is removed from "DevOps" but not "DevOps + Deployment Managers"? They'll still be able to access stuff that they should no longer have access to.)

Sounds like you'll be happy in a post T3670 world. :D