Less el-autho.

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.

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

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?