Making an attempt here. This adds the ability to set Projects on Dashboards and Dashboard Panels. Most of this went smooth, but I can't figure out why the queries don't automatically show searching by Projects. I'm stumped. Rest seems fine.
Details
Details
- Reviewers
epriestley btrahan - Commits
- Restricted Diffusion Commit
rP6be53bd91608: Add Projects to Dashboards and Panels
Assign a Project to a Dashboard and a Panel, see Project show up, edit it, see transactions.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- dashboard-query
- Lint
Lint Passed - Unit
Tests Passed - Build Status
Buildable 7319 Build 7678: [Placeholder Plan] Wait for 30 Seconds Build 7677: arc lint + arc unit
Event Timeline
Comment Actions
I made progress here, but I'm stumped. Even though it lets me put in a project, it doesn't really return it as sorted results. I think I borked something in the conversion. In Panels I have other issues.
| src/applications/dashboard/query/PhabricatorDashboardPanelQuery.php | ||
|---|---|---|
| 35–41 | I get this error here: Attempting to use a panel in a way that requires an implementation, but the panel implementation ("") is unknown to Phabricator.And I can't find any (easy) means of resolving it. Am I in over my head? I think I have to some fancy initializing like in Alamac's query, but not sure what the magic sauce is. | |
Comment Actions
The error is because DashboardPanel is a bit unusual.
The SearchEngine sees that DashboardPanel implements PhabricatorCustomFieldInterface, so it says "okay, I'm going to get a list of the custom fields on this object so I can let the user search for them". In normal applications like Maniphest, this lets us automatically expose custom fields in ApplicationSearch without requiring extra code.
However, for Dashboard panels, the custom fields depend on the type of the panel, and the panel returned from newResultObject() doesn't have a type.
I think the easiest fix is to just give it a basic type for now:
diff --git a/src/applications/dashboard/query/PhabricatorDashboardPanelQuery.php b/src/applications/dashboard/query/PhabricatorDashboardPanelQuery.php index cbfe163..3a6589a 100644 --- a/src/applications/dashboard/query/PhabricatorDashboardPanelQuery.php +++ b/src/applications/dashboard/query/PhabricatorDashboardPanelQuery.php @@ -33,7 +33,15 @@ final class PhabricatorDashboardPanelQuery } public function newResultObject() { - return new PhabricatorDashboardPanel(); + // TODO: If we don't do this, SearchEngine explodes when trying to + // enumerate custom fields. For now, just give the panel a default panel + // type so custom fields work. In the long run, we may want to find a + // cleaner or more general approach for this. + $text_type = id(new PhabricatorDashboardTextPanelType()) + ->getPanelTypeKey(); + + return id(new PhabricatorDashboardPanel()) + ->setPanelType($text_type); } protected function buildWhereClauseParts(AphrontDatabaseConnection $conn) {
This isn't the cleanest thing in the world, but should fix the issue without causing any fallout, and we can maybe find a better fix eventually (some other applications, like Harbormaster, might run into similar issues).
| src/applications/dashboard/query/PhabricatorDashboardPanelSearchEngine.php | ||
|---|---|---|
| 14–42 | Since you now implement buildCustomSearchFields(), you should remove these and implement buildQueryFromParameters() instead (basically, convert buildQueryFromSavedQuery() -- the old way of doing things -- into buildQueryFromParameters() -- the new hotness). | |
| 54 | Although paneltypes is probably a better key for this, you should retain the old key so we don't break anyone's saved searches (that is, using a one-character-better internal key probably isn't worth potentially breaking / annoying some users). | |