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

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.

Change method name, remove extraneous argument.

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".

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?

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"?

While you're here, have you taken a look at T13273?

In D20335#255596, @epriestley wrote:

I think knowing how to refine the query might be helpful, especially for more technical users.

In D20329#255482, @amckinley wrote:

Makes preview behavior work correctly. Still doesn't quite do the right thing: the value is getting mangled when the rules come out of the DB, but not on the way in.

Makes preview behavior work correctly. Still doesn't quite do the right thing: the value is getting mangled when the rules come out of the DB, but not on the way in.