I've marked D14699 as fixing this, but it only applies to the EditEngine form, see T9905.

Hrrm, double header in the quick create menu is a little weird. Maybe I'll just drop the first header completely, I think it's fairly easy to figure out what the menu is doing.

Notes for me / the curious:

I'm not a big fan of haunt mode and think it's near the top of the "dumbest features" pile, but it's easy to bring everywhere if you're more of a fan. And maybe we're stuck with doing that anyway one Differential folds into EditEngine.

Let me at least see if I can tweak the text a little bit, I think this rule can be made more clear than it is.

The logic is "if they've seen them before".

Git 2.5 is less than 6 months old and we haven't seen other interest in this, so it will probably be a while before we get to it, but it's reasonable for us to try to accommodate this better.

I'm going to merge this into T5953, which discusses building a general bulk import workflow (from CSV, LDAP, an external system, etc).

Alright, I'll just replace "Add Projects" with "Change Projects".

From elsewhere:

This does not describe a bug in Phabricator. See Support Resources and Contributing Bug Reports.

I just think this isn't very good:

For what it's worth, I think that this is a reasonable request. I think that the only way to implement this would be to use a custom message which would be specified in the .arclint file. For example:

Yeah, just a mobile issue.

Nice.

I assume the use case for this is building tables in, e.g., Phriction documents with the status of various tasks.

Apparently this is just how <textarea> works. Here's a test case in WebKit explicitly testing this behavior:

I also made them work in Paste, so generalizing this task per D14416.

I implemented this a while ago:

This task doesn't describe a root problem. See Contributing Feature Requests for modern documentation on feature requests.

In any case, we can't reproduce this and aren't sure if it reproduces at HEAD. See Contributing Bug Reports.

See also D14665 for EditEngine integration, which slightly changes one call.

We haven't seen other requests for this and I think putting administrators in a project and using "Pusher's projects ..." is a pretty reasonable workaround. This can also now reasonably be written as an extension.

We haven't seen other requests for this in a year, and our behavior is technically correct and I think it is broadly reasonable.

I don't think this is a good fit for the upstream: it's inherently a bit unreliable, can't be made reliable, and I don't think the use case described here is a particularly robust one even if it's reasonable for some organizations.

This doesn't describe a use case (per Contributing Feature Requests) except by reference to requiring projects (which is covered by T6030).

At HEAD, you can now edit this field via the owners.edit Conduit API method.

No clue how to reproduce. If you see it again, grab the field value too? My guess is that it's something like the reviewer PHID ending up as the project PHID instead of your PHID and "Reviewer" needing to be updated to "Reviewers" or similar.

This is related to T5158, I'm going to split things up like this:

Ah, I figured out how to reproduce this.

I think it wasn't that bad thanks to a similar set of changes elsewhere from D14669, which I wrote yesterday.

Oh, I should have read that comment more carefully. You tested more thoroughly than I did.

This no longer reproduces for me at HEAD in EditEngine (see T9905), although I can't immediately reproduce it in the old editor either. Since it seems like it got fixed somewhere I'm not going to worry about it too much.