In T8044#111257, @eadler wrote:

I want to be able to see every user that has access to my phabricator install.

Does this command work properly when run from /var/repo/XYZ, where 'XYZ' is the repository callsign?

This use case is very far outside the mainstream and not a good fit for the upstream.

T6560 is essentially the same issue, but specifically with tabbed panels.

T8034 is half of the "similar, less-severe" issue I mention above.

Easiest fix is probably for files in /__tests__/ directories to not trigger inclusion of other files. I think it's reasonable in the general case that if you only touched /__tests__/x.php, we only run that file, rather than doing the full cascade into all adjacent/parent tests.

What problem are you trying to solve?

I think (2) is the right way to go so I kicked this into T5378. I'd maybe still render them as URLs but they should definitely trigger mentions.

I think the original proposal was to make the panel disappear. This isn't something we'd be likely to implement, for the reasons @chad gave: it's super confusing and doesn't give users any tools to understand the behavior.

Yeah, I think you have to write a bit of JS since every other menu we have either gets generated via JS or has at least one item in it that needs JS.

the svn / no svn issue should be fixed

For (1), what output do you expect?

One possibility here is to reopen a Maniphest task if a "fixes" commit is reverted. I'm not sure whether this behavior is desirable.

such mentions

I can't reproduce it either, including on Firefox/OSX.

prevents typing "tea time", not acceptable

@lpriestley hit this earlier too.

Story is pretty much the same a year later, so I'm just going to update the "today" in the description. :3

• See T5873 for ApplicationTransactions in Conduit (adding members).
• See T3980 for binding to external sources.

Reopen if this crops up again.

wut

Okay, I think we should do this:

Particularly, although it's conceptually simpler, paging/ordering is probably even messier. Paging/ordering is simpler if we have a single total order relation across all events, even if the order isn't exactly correct in some timezones.

An alternative is to only store date information for these events, then do two separate queries for time ranges:

I think this is:

I think the best way to do this is to create a new class to represent the state of a date control, like AphrontFormDateControlValue or something. Currently, AphrontFormDateControl has most of this logic, but that's awkward since it serves as both a Control and a value. This class will have fields like:

From a technical point of view, I think this looks like:

• Write a subclass of HeraldAdapter. I think PhrictionDocumentHeraldAdapter is a fairly reasonable example.
• In HeraldTestConsoleController, you have to add a hacky piece of code to help Herald figure out which adapter to use.
• In your Editor, implement shouldApplyHeraldRules(), buildHeraldAdapter() and didApplyHeraldRules().
• You should now be able to use the test console to test rules.

For outbound mail:

I'm just going to merge this into T1562, I don't expect to really touch this page before that obsoletes it.