This may mostly have been covered by D20469, although that change does not extend to reverting/reopening tasks.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 19 2019
May 17 2019
This stuff is largely resolved, but survived by a few remaining issues in T13290.
Not actively working on this.
Moving this to [[https://github.com/freelancer/flarc | flarc]].
Moving this to [[https://github.com/freelancer/flarc | flarc]].
Not actively working on this.
Not actively working on this.
This code is gone.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
Not actively working on this.
May 16 2019
I'll hold this until after the release cut anyway since errors here are unusually dangerous (they can lead to XSS very easily), but I think it would also be hard to get this wrong without breaking a lot of unit tests and UI behavior in fairly obvious ways.
- Choose less-misleading constants and notations for the examples.
- Rewrite the example documentation to more clearly follow the new execution flow.
- Clarify the "child tokens appear first" explanation.
- Make encountering an invalid token ("01234" or "99999") throw. It should be impossible for invalid tokens to appear anywhere.
- Make encountering an out-of-order token (for example, token 30 while we're processing token 20) throw. It should be impossible for out-of-order tokens to appear anywhere.
I've been staring at this long enough that I can plausibly claim to understand how it works. Put this on the pile of "terrible interview questions that I'm sure someone somewhere is getting asked".
In either case, not an API change, just a nomenclature change.
I only blamed around a little bit, but I'm nearly certain they were named incorrectly from the beginning.
Doing this right (or, at least, more right) is probably about 20 lines of code and would make transaction.search a little more useful, so I may just take a stab at it at the end of this series.
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.
May 15 2019
- 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: