Since shouldDisplayGroupWith() includes a 2-minute cutoff and requires transactions have the same author, and we merge transactions that are part of the same edit before applying them (so if you submit 100 "edit title" transactions at the same time, we only actually apply the last one, since none of the others have any effect) I think you could only generate a group with 100+ transactions by writing a script that repeatedly edited the same field to different values very quickly. This seems very unlikely, even given the great ambition I ascribe to our users.

Oh, the relevance is that PhabricatorDatasourceEngineExtension now handles "doing magic stuff when you type things into the global search bar" (like jumping to a task when you type T123), and the next change was making "type a URI" mean "navigate to that uri" -- which got a mention in T5378, although it isn't the primary focus of that task.

For all who might need to migrate from trac to Phabricator, feel free to borrow from this bare-bone script: https://gitlab.com/simevo/trac2phab

I didn't go all the way down the rabbit hole on this, but it's not immediately obvious to me that this is actually relevant to T5378.

• In HeraldTranscriptQuery, attach the object we load (if the transcript has an object).
• Later, just getObject() it.

HeraldTranscriptQuery already requires that you must be able to see the object, it just doesn't actually attach it anywhere. Possibly a cleaner fix is to make it do that.

Part of the reason this works is that str_replace(), even in list mode, is basically running a loop over the string. That is:

Probably obsoleted by D18839?

Can you file a task for this that has step-by-step reproduction instructions (e.g., run this command, then run this command, here's where the thing breaks before this change)? I think this change is likely fine, I'm just not confident I'll be able to reproduce the issue when this refactors during T13098.

Thanks for the reviews :)

This is intentional, since "type a list of IDs into a box" is a pretty rough interface and this capability doesn't seem terribly useful in the general case (i.e., I think it would likely add more complexity than utility).

See D19868.

I like this goal achieved by this change -- it's silly that edge validation isn't really extensible anywhere -- but I think this also digs us deeper into the mess of T13248.

Remove a TODO comment that is no longer relevant

pass the applied transactions to Herald