2013-12-26 21:30:36 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class DrydockLogController
|
|
|
|
extends DrydockController {
|
|
|
|
|
Move Drydock logs to PHIDs and increased structure
Summary:
Ref T9252. Several general changes here:
- Moves logs to use PHIDs instead of IDs. This generally improves flexibility (for example, it's a lot easier to render handles).
- Adds `blueprintPHID` to logs. Although you can usually figure this out from the leasePHID or resourcePHID, it lets us query relevant logs on Blueprint views.
- Instead of making logs a top-level object, make them strictly a sub-object of Blueprints, Resources and Leases. So you go Drydock > Lease > Logs, etc., to get to logs.
- I might restore the "everything" view eventually, but it doesn't interact well with policies and I'm not sure it's very useful. A policy-violating `bin/drydock log` might be cleaner.
- Policy-wise, we always show you that logs exist, we just don't show you log content if it's about something you can't see. This is similar to seeing restricted handles in other applications.
- Instead of just having a message, give logs "type" + "data". This will let logs be more structured and translatable. This is similar to recent changes to Herald which seem to have worked well.
Test Plan:
Added some placeholder log writes, viewed those logs in the UI.
{F855199}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9252
Differential Revision: https://secure.phabricator.com/D14196
2015-10-01 17:06:23 +02:00
|
|
|
private $blueprint;
|
|
|
|
private $resource;
|
|
|
|
private $lease;
|
|
|
|
|
|
|
|
public function setBlueprint(DrydockBlueprint $blueprint) {
|
|
|
|
$this->blueprint = $blueprint;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getBlueprint() {
|
|
|
|
return $this->blueprint;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setResource(DrydockResource $resource) {
|
|
|
|
$this->resource = $resource;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getResource() {
|
|
|
|
return $this->resource;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setLease(DrydockLease $lease) {
|
|
|
|
$this->lease = $lease;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getLease() {
|
|
|
|
return $this->lease;
|
|
|
|
}
|
|
|
|
|
2013-12-26 21:30:36 +01:00
|
|
|
public function buildSideNavView() {
|
|
|
|
$nav = new AphrontSideNavFilterView();
|
|
|
|
$nav->setBaseURI(new PhutilURI($this->getApplicationURI()));
|
|
|
|
|
Move Drydock logs to PHIDs and increased structure
Summary:
Ref T9252. Several general changes here:
- Moves logs to use PHIDs instead of IDs. This generally improves flexibility (for example, it's a lot easier to render handles).
- Adds `blueprintPHID` to logs. Although you can usually figure this out from the leasePHID or resourcePHID, it lets us query relevant logs on Blueprint views.
- Instead of making logs a top-level object, make them strictly a sub-object of Blueprints, Resources and Leases. So you go Drydock > Lease > Logs, etc., to get to logs.
- I might restore the "everything" view eventually, but it doesn't interact well with policies and I'm not sure it's very useful. A policy-violating `bin/drydock log` might be cleaner.
- Policy-wise, we always show you that logs exist, we just don't show you log content if it's about something you can't see. This is similar to seeing restricted handles in other applications.
- Instead of just having a message, give logs "type" + "data". This will let logs be more structured and translatable. This is similar to recent changes to Herald which seem to have worked well.
Test Plan:
Added some placeholder log writes, viewed those logs in the UI.
{F855199}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9252
Differential Revision: https://secure.phabricator.com/D14196
2015-10-01 17:06:23 +02:00
|
|
|
$engine = id(new DrydockLogSearchEngine())
|
|
|
|
->setViewer($this->getRequest()->getUser());
|
|
|
|
|
|
|
|
$blueprint = $this->getBlueprint();
|
|
|
|
if ($blueprint) {
|
|
|
|
$engine->setBlueprint($blueprint);
|
|
|
|
}
|
|
|
|
|
|
|
|
$resource = $this->getResource();
|
|
|
|
if ($resource) {
|
|
|
|
$engine->setResource($resource);
|
|
|
|
}
|
|
|
|
|
|
|
|
$lease = $this->getLease();
|
|
|
|
if ($lease) {
|
|
|
|
$engine->setLease($lease);
|
|
|
|
}
|
|
|
|
|
|
|
|
$engine->addNavigationItems($nav->getMenu());
|
2013-12-26 21:30:36 +01:00
|
|
|
|
|
|
|
$nav->selectFilter(null);
|
|
|
|
|
|
|
|
return $nav;
|
|
|
|
}
|
|
|
|
|
2015-01-06 21:34:58 +01:00
|
|
|
protected function buildApplicationCrumbs() {
|
2013-12-26 21:30:36 +01:00
|
|
|
$crumbs = parent::buildApplicationCrumbs();
|
Move Drydock logs to PHIDs and increased structure
Summary:
Ref T9252. Several general changes here:
- Moves logs to use PHIDs instead of IDs. This generally improves flexibility (for example, it's a lot easier to render handles).
- Adds `blueprintPHID` to logs. Although you can usually figure this out from the leasePHID or resourcePHID, it lets us query relevant logs on Blueprint views.
- Instead of making logs a top-level object, make them strictly a sub-object of Blueprints, Resources and Leases. So you go Drydock > Lease > Logs, etc., to get to logs.
- I might restore the "everything" view eventually, but it doesn't interact well with policies and I'm not sure it's very useful. A policy-violating `bin/drydock log` might be cleaner.
- Policy-wise, we always show you that logs exist, we just don't show you log content if it's about something you can't see. This is similar to seeing restricted handles in other applications.
- Instead of just having a message, give logs "type" + "data". This will let logs be more structured and translatable. This is similar to recent changes to Herald which seem to have worked well.
Test Plan:
Added some placeholder log writes, viewed those logs in the UI.
{F855199}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9252
Differential Revision: https://secure.phabricator.com/D14196
2015-10-01 17:06:23 +02:00
|
|
|
|
|
|
|
$blueprint = $this->getBlueprint();
|
|
|
|
$resource = $this->getResource();
|
|
|
|
$lease = $this->getLease();
|
|
|
|
if ($blueprint) {
|
|
|
|
$id = $blueprint->getID();
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
pht('Blueprints'),
|
|
|
|
$this->getApplicationURI('blueprint/'));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
$blueprint->getBlueprintName(),
|
|
|
|
$this->getApplicationURI("blueprint/{$id}/"));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
pht('Logs'),
|
|
|
|
$this->getApplicationURI("blueprint/{$id}/logs/"));
|
|
|
|
} else if ($resource) {
|
|
|
|
$id = $resource->getID();
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
pht('Resources'),
|
|
|
|
$this->getApplicationURI('resource/'));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
Remove names from Drydock resources
Summary:
Ref T9252. Long ago you sometimes manually created resources, so they had human-enterable names. However, users never make resources manually any more, so this field isn't really useful any more.
In particular, it means we write a lot of untranslatable strings like "Working Copy" to the database in the default locale. Instead, do the call at runtime so resource names are translatable.
Also clean up a few minor things I hit while kicking the tires here.
It's possible we might eventually want to introduce a human-choosable label so you can rename your favorite resources and this would just be a default name. I don't really have much of a use case for that yet, though, and I'm not sure there will ever be one.
Test Plan:
- Restarted a Harbormaster build, got a clean build.
- Released all leases/resources, restarted build, got a clean build with proper resource names.
Reviewers: hach-que, chad
Reviewed By: hach-que, chad
Maniphest Tasks: T9252
Differential Revision: https://secure.phabricator.com/D14213
2015-10-01 17:13:43 +02:00
|
|
|
$resource->getResourceName(),
|
Move Drydock logs to PHIDs and increased structure
Summary:
Ref T9252. Several general changes here:
- Moves logs to use PHIDs instead of IDs. This generally improves flexibility (for example, it's a lot easier to render handles).
- Adds `blueprintPHID` to logs. Although you can usually figure this out from the leasePHID or resourcePHID, it lets us query relevant logs on Blueprint views.
- Instead of making logs a top-level object, make them strictly a sub-object of Blueprints, Resources and Leases. So you go Drydock > Lease > Logs, etc., to get to logs.
- I might restore the "everything" view eventually, but it doesn't interact well with policies and I'm not sure it's very useful. A policy-violating `bin/drydock log` might be cleaner.
- Policy-wise, we always show you that logs exist, we just don't show you log content if it's about something you can't see. This is similar to seeing restricted handles in other applications.
- Instead of just having a message, give logs "type" + "data". This will let logs be more structured and translatable. This is similar to recent changes to Herald which seem to have worked well.
Test Plan:
Added some placeholder log writes, viewed those logs in the UI.
{F855199}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9252
Differential Revision: https://secure.phabricator.com/D14196
2015-10-01 17:06:23 +02:00
|
|
|
$this->getApplicationURI("resource/{$id}/"));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
pht('Logs'),
|
|
|
|
$this->getApplicationURI("resource/{$id}/logs/"));
|
|
|
|
} else if ($lease) {
|
|
|
|
$id = $lease->getID();
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
pht('Leases'),
|
|
|
|
$this->getApplicationURI('lease/'));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
$lease->getLeaseName(),
|
|
|
|
$this->getApplicationURI("lease/{$id}/"));
|
|
|
|
|
|
|
|
$crumbs->addTextCrumb(
|
|
|
|
pht('Logs'),
|
|
|
|
$this->getApplicationURI("lease/{$id}/logs/"));
|
|
|
|
}
|
|
|
|
|
2013-12-26 21:30:36 +01:00
|
|
|
return $crumbs;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|