The fix should basically stub all the documents out all the way to the root.

@bitglue - Thanks for the report; we'd likely have never found this on our own given the "blank wiki" step. :D Just an FYI that the "Permissions should not be an issue because I'm an admin." thing is usually false in Phabricator. See https://secure.phabricator.com/book/phabricator/article/users/#administrators for some details.

I think it would also be acceptable to require creation of a root document as the first document, if that's an easier fix. Not sure if it would end up being a weird special case, but it might reduce surprises down the road (where a root document is created and has sweeping policy effects).

This kind of butts up against T6496. Post T6496, if the user wants to make some

x/y/z

but can't see

x/y

We don't let them make x/y/z. "Can't see" is currently coded as "Can't see or doesn't exist", since its just a policy query with the user as actor. This issue can thus be reproduced by trying to create some document where its direct parent doesn't exist.

My proposed fix would be to put some logic in PhrictionEditController around line 66 or so when we initializeNewDocument that detects a "no parent(s)" case and presents a very helpful dialogue about the ancestry that must be created. I would also leave the editor as is so it catches this issue very aggressively in other end points.

I think in the general case (creating x/y/z/ when x/ exists but x/y/ does not) auto-stubbing the parents would be reasonable (that is, create x/y/ as a stub with implied permissions, by copying the permissions of x/). If we require x/y/ to exist and make the user go create it, they can still get back to the same state by deleting it later, so we aren't guarding against an invalid state. I'm not sure how useful it really is to create x/y/z/ when no x/y/ exists, but permitting it doesn't seem totally unreasonable.

Auto-stubbing / if x/ is the first created page seems reasonable too, I'm just wondering how often this might be user error or an opportunity to onboard better, or later become confusing if / has permissions adjusted when someone isn't happy with the implicit default permissions. It seems like we probably need some special casing here if we auto-stub (i.e., for x/y/ with x/ existing we can copy permissions from x/, but when / does not exist I think we have to special case the default permissions, so presumably we could throw there instead). This might also just be overcomplicating things, but I could imagine a future where we show an orientation page at / when it doesn't exist yet, and require it to be set up first to make sure users understand the policy rules.

That said, I think throwing in all cases and requiring parents explicitly (the solution you outline) is fine too (and definitely simplest), unless some user comes up with some amazing use case for creating parentless documents.