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.

Defining permissions for newbies that may be distinct from the "got the hang of it" crowd

(You could put more ignore stuff in the route too if you want the blog title.)

You can probably just do that by adding a route like this:

Yes, but blogs don't have slugs right now and blog post slugs are editable.

The interaction between Maniphest "Can Edit X" fields and the new form stuff is also currently quite bad. I've restored 'Can Prioritize Tasks' to "All Users" on this install, since users otherwise can not create tasks with the new forms.

The story on SNI actually looks pretty reasonable (we're mostly just losing IE on XP and very old mobile devices), and should be more reasonable by the time we're thinking about whitelabeling main instances.

It's also possible that we can roll our own loadbalancers by assigning a lot of elastic IPs to a single host. This currently allows us to put ~240 domains on a host, at a cost of ~$4 per domain per month (for the elastic IP) instead of ~$20 per domain per month, but is more work. In contrast, SNI would let us put thousands of domains on a host with no cost per domain.

One other thing is that custom domains won't work on Phacility by default, and I don't think we can easily make them work (we can't just have users CNAME their DNS because we won't have the right SSL certificate). So maybe that's an argument for removing the feature or adding an option (ugh) to disable it.

I'm consistently not seeing a comment preview on T9910. Likely trace:

The major product issue I'm now unsure about is what form we should use when you interact with the create/edit flow from places other than Maniphest → Create Task. Exhaustively, I believe these are:

That makes sense, and should work well if you're able to convince developers to use arc feature (or the underlying branch flags, or I think branch.autosetupmerge in Git config?) consistently. You might also consider leaving git:branch-unique(...) in the ruleset after arc:upstream -- it should behave well in more situations than git:merge-base(...) will, I think, and it might be preferable if the penalty for not using --track is "things work, but are slow" instead of "things don't work".

Just to be clear, after this week - sites that upgrade but are tracking the stable branch will be affected by these changes?

Policy junk should be fixed.

The basics of the ApplicationEditor stuff are now live on this install, and T9908 has some discussion of the direction I think we can pursue for the "Security" use case.

Edit forms are causing some policy checks to apply incorrectly so tasks (which should be public) currently aren't. Looking into that...

One severe regression is that the description textarea in the create form is tiny now. I need to make that gigantic again.

I landed what I've got so far, pushed it here, configured it a bit, and described what I've done in T9908, for the curious.

Cool, let us know if you run into anything else.

(At the least, I can't reproduce these issues at HEAD.)

You're a few days out of date -- I believe both of these issues are fixed at HEAD. Can you upgrade and let me know if you're still seeing issues?

Specifically, you're talking about this?

will the patch be reviewed and merged

That's the workflow I use, but I --amend "feature" when updating it.