Page MenuHomePhabricator

Modularize Dashboard Panel transactionns
ClosedPublic

Authored by epriestley on Tue, Apr 2, 5:00 PM.

Details

Summary

Depends on D20369. Ref T13272. Move toward a world where we can edit panels with just one controller, instead of separate "Edit" and "Editpro" controllers.

Test Plan

Created and edited panels. This will get vetted more thoroughly after additional changes.

Diff Detail

Repository
rP Phabricator
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Tue, Apr 2, 5:00 PM
epriestley requested review of this revision.Tue, Apr 2, 5:01 PM
amckinley accepted this revision.Wed, Apr 3, 6:53 PM
amckinley added inline comments.
src/applications/dashboard/xaction/panel/PhabricatorDashboardPanelNameTransaction.php
64–69

Isn't this the default implementation for ModularTransactions?

This revision is now accepted and ready to land.Wed, Apr 3, 6:53 PM
epriestley added inline comments.Thu, Apr 4, 2:43 PM
src/applications/dashboard/xaction/panel/PhabricatorDashboardPanelNameTransaction.php
64–69

By default, we don't expose anything to Conduit.

Some transactions have complex/weird/sensitive/not-good-for-API-users details, and if we exposed them by default we might end up in trouble (maybe users trying to use them and complaining that they're impossible to work with; maybe users complaining that we broke compatibility if we then fix it; maybe actual security problems), so we err on the side of caution and require each transaction have an explicit implementation.

In this case (and other simple cases) there's an obviously reasonable way to represent the transaction, but I just delete / don't implement these methods a lot of the time if there's any ambiguity.

Usually, this only impacts webhooks trying to do something with the event.

This revision was automatically updated to reflect the committed changes.