If we make "Must Encrypt" stateful, that flag should also probably live in this table.

The scope on T13053 didn't end up making it very far in this direction so I think this missed the boat for now.

T11934 plans to add these commands everywhere. If they're available all over the place, it might be less necessary to add reminders.

D19032 now renders D123 in text contexts (plaintext email) as D123 <https://dev.tyrellcorp.com/D123> instead of https://dev.tyrellcorp.com/D123.

I'm not sure how to reproduce whatever remaining issues are described here so I don't see how to move this forward.

D19030 marks this as fixed: it removes this documentation.

I'm going to merge this into T10448, which exposes this information in an X-Header and optionally in mail bodies.

(I think everything actionable here was addressed, or survives in followups.)

I've marked D19029 as resolving this since it fixes the last one of these that I'm aware of. HTML mail has been the default for a long time now so this presumably isn't really causing problems even if there are other cases.

@kislinsk Is it possible to externalize your solution? I have no information about the status of Phabricator supporting extensions but when there is a way to separate your solution from the core cleanly, why not creating a repository on GitHub? I would love to use this right now! :D

As it turns out, I wrote a bit of {icon ... size=72} yesterday but ran into a related issue: it's hard for us to tell if the X in {icon X} is a single character or not.

Would you want to include the use case of making specific letters/words of inline text larger/smaller/bouncier? I like the idea of {style ...} though it is awfully similar to {icon ...}

See PHI178 and PHI126. See T12689. When users resign from a revision, they should not receive mail about it even if they're a member of a non-resigned package or project. This requires propagating mail recipients deeper into the stack, and retaining richer recipient information. Subscriptions should be upgraded to support a stronger "unsubscribe" which can get you out of indirect subscriptions via projects/packages/etc. These probably mostly go down the same pathway.

If D19012/D19013 turn out badly this table should be <objectPHID, mailKey, firstSubjectWeSentMailWith> so there's some vague argument for waiting until those are in the wild for a little bit or naming the table in a more generic way (MailObjectMetadata instead of MailObjectKey).

I've been running into the same issue for a while now. Using the Default Policy set to Subscribers for Files works well when adding files to Phriction pages and Maniphest tickets. However, when adding binary files as part of a Diff the creator of that Diff needs to change each files permissions by hand before a reviewer can download the Diff. Moreover, this needs to be repeated for every new version of that Diff.

In T9608#226589, @epriestley wrote:

(T12812 wants custom headers, but the only use case appears to be better covered by T12813.)

Presuming this is a version issue or evil spirits or something until some contrary evidence surfaces.

Some other possibilities:

It's a real tragedy. The biggest header is definitely unacceptable for huge emoji.

Currently there's no way to make an increasingly larger parade of dogs

=====:dog2:=====
====:dog2:====
===:dog2:===
==:dog2:== 
=:dog2:=

Yeah, the only reason I pursued this was for giant emoji. I was just going to do {huge 🐱} or something first, but then I figured {drop-cap 🐱} was a little more defensible as a general feature while still solving the huge emoji problem.

I've been wanting to make a "giant emoji" task since emoji were added but was too afraid...

In T5726#88706, @epriestley wrote:

One concern about this is that this information is policy-bypassing.

I'd either want to pay some service to deal with this or run an open source server that I was confident it was possible to fix, but one option is definitely to run Postfix/Dovecot/Exim/whatever the kids use these days.

If all you're going for are emails, why not spin up your own Exchange server (or whatever the kids use these days)? With maybe forwarding to a epriestley-phacility@gmail.com so you remain compliant?