Really awesome.

This one is totally my bad.
My intention was to make it less spooky to migrate individual pieces to the section construct (since the API remained largely the same), but the API weirdness was not worth it, and didn't even achieve that goal

It would be nice (and maybe pretty complex) for (3) to work if you happen to use S3 (which would work if you instance is behind VPN), although right now the Phabricator guide does not recommend using it.

What about inlining the images with data:base64 ?
Sure it will make emails with images bigger, but it will always work and most emails don't have macros.

project.query does not emits the auxiliary dictionary, so there's no way of getting custom field value with the api :(

Cool. I'll chop em up and send patches.

I mean, make v1 also do diffs (because they are so easy compared to remarkup), which is pretty much D9375 plus minor fixes plus per-user config. I can also rip that part out if you'd prefer, although we found it to be useful.

Yeah, this needs some poking around, although I'm leaning towards teaching PhutilRemarkupBlockRule how to render things for email.
There's just one render target right now I think. The text rendering just dumps the remarkup as is.

• Cool, I'll add the formatting option.
• Correctly rendering remarkup blocks might be a little hairy, as it requires inlining CSS. Maybe we need to teach PhutilRemarkupBlockRule how to render tags for email, or figure out some post-processing css inline pass?

oops! I did search for it, but my feng shui was misaligned.

I see. Is there a ticket for the filter-by-project reworking? I couldn't find one

We have the exact same issue. it makes Phabricator "feel" spammy.

D9375 works reasonably well, but need to verify that it doesn't break reply-by-email in popular email client (see differential review for details)

I personally dislike it the addition to the body, as it adds more metadata to scroll through before I can get into the comments.

What about something like T5244?
We use [REPO/BRANCH] [Differential] <...> for our email subjects, and it's super convenient.

Also interested in this. It could maaaybe reduce reliance on email </wishful thinking>

That would close CRs that haven't been pushed, though.
What about having it check with diffusion first? If it's there, close. Otherwise it will get closed normally when diffusion sees it.

The issue here is that some users want to push directly to master, and have the code reviewed post-push (so there's no arc land).

(wait = don't do anything on push, and as soon as it's accepted it queries diffusion for the commit to see if it's there)

Ha! That is awesome.
How does autoclose work in those cases? Does it wait for it to be accepted before switching it over to closed?

Hey Evan!
Some updates on this (we've already discusses some of these, but I'm just summarizing them here for reference sake):

Awesome!

How would it work with T4344, though? Also query with a project id?

btw, we should probably add this to the "Configuring Inbound Email" article

haha. ok.