One overarching issue here is that facts don't have a clear permissions model. It's bad if anyone can go look up the burndown chart for #critical-security-issues and then correlate that chart against tasks showing up in #weird-things-that-happen-when-you-hold-down-the-letter-a or whatever and get a hint about a security concern. In the general case, charts like "Salary by Employee", "Acuisitions Affecting our Stock Price", etc., are also potentially problematic.

• Fact cursors are currently per-object. I think they should likely be per <object, engine> pair so that subsets can be rebuilt more quickly for testing/development and the failure of one engine will not stop all other engines from processing data. On the other hand, fact processing is currently pretty fast and I don't expect to write a ton of engines so I'm not sure how critical this really is. Engines likely don't care how cursors work unless they depend on facts extracted by other engines and need to guarantee they execute later.
• FactEngine->getFactSpecs() isn't really authoritative -- it takes a fact definition externally. I think this should become the authoritative generator. That is, this piece of code needs to go sooner rather than later:

D19111 doesn't fix this in the general case, but should produce the desired behavior for most inputs such that the input is in the form [x](y) and y is the URI of a Wikipedia article.

The intent isn't unambiguous in the general case, consider: Blah blah (see also [x](y)).

The non-bold ones also open in a new tab.

Oh! Yes. Sort of.

This doesn't look like a bug in Phabricator; the reporting user is likely discussing client-side mail filtering rules which, by design, can never work against "Must Encrypt" mail.

Comment 3: Self mail on again.

Comment 2: Self mail off.

Comment 1: Self mail on.

A similar "attack" is to send a link to two destinations based on the viewer:

We haven't seen other interest in this and the use case feels a little unusual (I suspect 15-20% empty documents is very unusual) so I don't plan to implement it at this time.

I'll follow up with more details on what was accessed once we conclude our response.

See PHI372 -- setting user.custom-field-definitions (or, probably, any similar config) to a string will pass validation but then fatal in use.

No. Mail stamps are not intended to answer "Why am I receiving this mail?" in the general case (which lives in T9412 now, I think).

Example usage (for simplicity, requires at least one user named "Jake" on your install to function correctly):

After D19089, you can probably emit a projects(people-named-jake()) token or whatever and have it work for some values of "work" and "whatever". Tentatively, it doesn't look like this needs a lot of API changes, so I'm going to move forward with the simple version of the original request.

@avivey, heads up that I'm renaming PhabricatorQuickSearchEngineExtension to PhabricatorDatasourceEngineExtension. I'm leaving an empty subclass in master for now so that nothing breaks, but will delete it sooner or later, so rename QuickSearch to Datasource in your extends ... statements (and, ideally, class names) at some point before then to keep things working smoothly.

Quicksand isn't really bound by natural law, but I think that might fix it.

A workaround is to turn off the little inline chat thing so Quicksand disables itself, but this should be an easy fix.

We got a printer fax spam support request into the completely private Support app today. 😑

Phriction already has modular transactions, but does not have an EditEngine. That likely needs to happen first.

This never got fleshed out into an actionable plan, see T13077 for the next planned phase here.