I have edited the description in order to bring Maniphest in, as discussed above. In Wikimedia we are finding ourselves in this problem too often.

Yeah I wasn't sure whether to generalise this or open a new task. In BZ we'd have to open new bugs, but here we can just add extra projects... :)

This task I believe is specifically for Phriction, but maybe it is generalizable.

We ( Wikimedia ) see this problem (lack of conflict detection) often in Maniphest, but it probably applies to more than just these two projects... See https://phabricator.wikimedia.org/T78236

We've improved Remarkup and added "assist" buttons, similar to sites like GitHub, StackOverflow, and Quora. This seems generally satisfactory. We have no plans to pursue full WYSIWYG at this time.

This was resolved by rPedf8822.

Closed by commit rP905fc217b80c.

Closed by commit rP905fc217b80c.

We don't plan on pursuing this outside of the inline comments task.

How about add normal comments first? Allows other users (with or without edit access) leave comments below the wiki content.

I think this is related to T6651 in that this operation doesn't behave nicely if there's no hierarchy already.

BUT, moving the document to /w/stacks/ does work

The file is : /w/memo/aws/stacks/Stacks
Trying to move to: /w/aws/stacks/

I also can't reproduce. I made this structure

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.

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

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).

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

This would be cooler as a general remarkup feature instead of just Phriction.

inline-comment is really a good feature to have.

Closed by commit rPb85283105ece.

This is a regression imvho. Instead of 1:1, do many to many.

As you've guessed, the expectations around the automagicalness of the wiki <--> project link were hard to get right technically. Additionally, said automagicalness was considered too rigid by some, particularly as policy controls have become available throughout Phabricator.

A more integrated wiki is very interesting. Why did you remove this feature?

This change was intentional.

Closed by commit rP120a7d916447.

This is most definitely fixed at HEAD. Please do let us know if thats not working for you.

D10838 does not specifically handle the URI case as a special case, but it removes the misleading UI (which prompted you to enter a "URI"), provides more hints about expected format, and will prompt you to confirm before we use a modified form of what you entered (URIs hit this prompt, although mostly by accident). I think this should be sufficient to reduce confusion.

Yeah, I suspect this is fixed at HEAD.

Won't be able to re-upgrade and test that commit for another 10 hours or so as we're in the middle of migrating Harbormaster build logs for the utf8mb process (I moved the table and wrote a script to migrate the logs while Phabricator is online). Will try tomorrow.

99bcf06 fixed a number of Phriction queries

I am not able to repro at HEAD. Can you update and report back?

For some weird reason, the behaviour is:

Closed by commit rP8e1a4eef0400.

Closed by commit rP36c46d80f5a0.

Ah, that makes sense.

This repros at any new page, e.g. https://secure.phabricator.com/w/asdsadsadsadasd/

Closed by commit rPb462a80cca31.

Closed by commit rP9252d2a579e3.

https://github.com/phacility/phabricator/issues/759 notes a documentation issue too, although maybe @chad wants to steal some internet points.

Closed by commit rP6f971a0fc4d8.

Herald allows users to write rules which react to changes in objects they care about (for example, by notifying the user of the change). We'd like to support Phriction (the wiki) in Herald, so users can easily monitor changes to wiki pages. (One example use case is that I'd personally like to be notified about any edit to any wiki page on this install).

Also relevant, T5166 discusses a UI + infrastructure approach to letting long-running workflows (e.g., batch edit 1K tasks, move 1K documents) run through the web UI.

From T2685, a more complete spec from epriestley:

The magical projects stuff is gone. Any legacy documents have the project policy, and then otherwise folks can create documents whereever policy allows. See T4029 for details.

I can't find any sort of bug here anymore.

Closed by commit rPb655699a6cfb.

To see x/y/z/ you have to be able to see x/ and x/y/, so it should be moot I think.

Implementation wise, I think the handle fix is the way to go, mainly because....

For anyone waiting on this with bated breath, there are a couple of minor followups in T6495, T6496, and T6497 to iron out some details.