Less el-autho.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 11 2019
In D20400#256680, @epriestley wrote:This probably adds bullets all over the place, i.e. not only if there are multiple items. Try creating a task with no title, for example?
Oh whoops, I was editing the PhabricatorAuthProvidersGuidanceEngineExtension in rSERVICES.
I confess to skimming this because it's mostly code shuffling and also includes a convincing unit test.
Apr 10 2019
Requested changes.
Yeah, I mean, the reporter's not wrong...
In T13269#245817, @pasik wrote:well, I'd say for example the "Close as <status> (only acts if task is not already closed)" is useful, and definitely needed.
Move the task to "done" column on the workboard, and the task automatically gets closed. That's handy.
ok this time i got it
Oops.
Change rule to unconditionally add projects in transaction and let the editor figure it out.
Broadly, it's not clear to me that any of these rules are actually good/useful/worth building.
- Close as <status> (only acts if task is not already closed).
- Reopen as <status>.
BUT WHY DID YOU CROP THE PICTURE
Apr 9 2019
We probably can't really run this "alongside" the current production git endpoint without doing a ton of work, can we? It would be nice to watch this thing have byte-identical output to prod for a while before cutting over.
Apr 8 2019
Apr 5 2019
Change method name, remove extraneous argument.
Apr 4 2019
I found two existing bugs while writing this:
This was about 100x more complicated than I expected because I went around and around about how to handle getting the viewer context down to the level of the rule objects. It turns out there are quite a few ways to generate trigger and rule objects, and some of them make more sense than others for explicitly passing $viewer around. Settled on manually setting the viewer inside the controllers that need to work with triggers.
Pretty much everything works now, including drop action previews. Only breakage is UI stuff when changing the type of an existing trigger rule.
It's possible that we don't really need this anymore -- at the time, I think one panel immediately banished the whole board to the shadow realm, while everything degrades pretty cleanly now.
We'd have to make an assertion like "panels must have the same policy as the dashboard, or a strictly weaker policy".
Apr 3 2019
Ok this makes more sense now that I've looked at the follow up revisions.
Wait, we have both of PhabricatorDashboardPanelEditproController and PhabricatorDashboardPanelEditController, and they don't have the same code, and we're keeping both of them? Did you write one, forget about it, couldn't find it because of the incorrect name, and write it again?
Apr 2 2019
Apr 1 2019
I skimmed the other client-side error codes, and the only other condition that stood out as being another retry candidate was 2013, "lost connection to server". I'm happy to say "don't add it until someone asks for it", though.
The code looks pretty obviously correct to me, but maybe test the other case to make sure we aren't suddenly retrying for all error codes? Try, uh, error 2005, "Unknown MySQL server host"?