2015-01-12 19:04:01 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorProjectViewController
|
|
|
|
extends PhabricatorProjectController {
|
|
|
|
|
|
|
|
public function shouldAllowPublic() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
$request = $this->getRequest();
|
2015-08-08 19:34:55 +02:00
|
|
|
$viewer = $request->getViewer();
|
2015-01-12 19:04:01 +01:00
|
|
|
|
2015-12-27 11:04:37 +01:00
|
|
|
$response = $this->loadProject();
|
|
|
|
if ($response) {
|
|
|
|
return $response;
|
2015-01-12 19:04:01 +01:00
|
|
|
}
|
2015-12-27 11:04:37 +01:00
|
|
|
$project = $this->getProject();
|
2015-01-12 19:04:01 +01:00
|
|
|
|
2016-12-11 18:00:44 +01:00
|
|
|
$engine = $this->getProfileMenuEngine();
|
2016-12-11 19:08:26 +01:00
|
|
|
$default = $engine->getDefaultItem();
|
2015-01-12 19:04:01 +01:00
|
|
|
|
Allow "Manage" to be the default menu item for projects
Summary:
Fixes T13033. Currently (prior to D18836) all the default items for projects can be hidden. When this occurs, the main project page fatals.
If we fix the fatal narrowly (don't try to call `null->getBuiltinKey()` when `$default` is `null`), it would 404, which is a little better but not by much.
After D18836 you can't hide "Profile", which is pretty sensible, and effectively fixes this. This change doubles down: let "Manage" be a default, and send the user there if we can't find a different default.
Ideally, the MenuEngine itself will do more rendering eventually (as it does for some of the newer Home stuff) and could handle this defaulting behavior with less special casing, but we'd still end up in a similar situation if a project had only one "Link" item to "coolcats.com" or something: redirecting the user to "coolcats.com" is probably better than fataling, but not by a huge margin, and not likely to be what they expect.
Test Plan:
Before D18836, disabled both "Profile" and "Workboard" items on a project. Visited project page.
Before patch: fatal. After patch: manage page.
After D18836, you can't do this and just get the profile, so this is sort of moot and mostly future-proofing/for-completeness.
Reviewers: 20after4, amckinley
Reviewed By: amckinley
Maniphest Tasks: T13033
Differential Revision: https://secure.phabricator.com/D18843
2017-12-23 17:36:58 +01:00
|
|
|
// If defaults are broken somehow, serve the manage page. See T13033 for
|
|
|
|
// discussion.
|
|
|
|
if ($default) {
|
|
|
|
$default_key = $default->getBuiltinKey();
|
|
|
|
} else {
|
|
|
|
$default_key = PhabricatorProject::ITEM_MANAGE;
|
|
|
|
}
|
|
|
|
|
2016-01-22 14:33:21 +01:00
|
|
|
switch ($default->getBuiltinKey()) {
|
2016-12-11 19:08:26 +01:00
|
|
|
case PhabricatorProject::ITEM_WORKBOARD:
|
2015-01-12 19:04:01 +01:00
|
|
|
$controller_object = new PhabricatorProjectBoardViewController();
|
|
|
|
break;
|
2016-12-11 19:08:26 +01:00
|
|
|
case PhabricatorProject::ITEM_PROFILE:
|
2015-01-12 19:04:01 +01:00
|
|
|
$controller_object = new PhabricatorProjectProfileController();
|
|
|
|
break;
|
Allow "Manage" to be the default menu item for projects
Summary:
Fixes T13033. Currently (prior to D18836) all the default items for projects can be hidden. When this occurs, the main project page fatals.
If we fix the fatal narrowly (don't try to call `null->getBuiltinKey()` when `$default` is `null`), it would 404, which is a little better but not by much.
After D18836 you can't hide "Profile", which is pretty sensible, and effectively fixes this. This change doubles down: let "Manage" be a default, and send the user there if we can't find a different default.
Ideally, the MenuEngine itself will do more rendering eventually (as it does for some of the newer Home stuff) and could handle this defaulting behavior with less special casing, but we'd still end up in a similar situation if a project had only one "Link" item to "coolcats.com" or something: redirecting the user to "coolcats.com" is probably better than fataling, but not by a huge margin, and not likely to be what they expect.
Test Plan:
Before D18836, disabled both "Profile" and "Workboard" items on a project. Visited project page.
Before patch: fatal. After patch: manage page.
After D18836, you can't do this and just get the profile, so this is sort of moot and mostly future-proofing/for-completeness.
Reviewers: 20after4, amckinley
Reviewed By: amckinley
Maniphest Tasks: T13033
Differential Revision: https://secure.phabricator.com/D18843
2017-12-23 17:36:58 +01:00
|
|
|
case PhabricatorProject::ITEM_MANAGE:
|
|
|
|
$controller_object = new PhabricatorProjectManageController();
|
|
|
|
break;
|
Allow menu items to render their own content; make Dashboard items render on-page
Summary:
Ref T11957. When you click a dashboard item, it now sends you to `/<app>/item/view/123/`, which renders the proper crumbs, navigation, etc., with the dashboard as page content.
This works as you'd expect in Projects:
{F2508568}
It's sliiiightly odd in Favorites since we nuke the nav menu, but seems basically fine?
{F2508571}
Test Plan:
- Created a dashboard panel on a project.
- Clicked it, saw it render.
- Made it the default panel, viewed project default screen, saw dashboard.
- Disabled every panel I could, still saw reasonable behavior (this is silly anyway).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11957
Differential Revision: https://secure.phabricator.com/D17255
2017-01-26 21:14:02 +01:00
|
|
|
default:
|
|
|
|
return $engine->buildResponse();
|
2015-01-12 19:04:01 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return $this->delegateToController($controller_object);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|