2013-12-03 11:09:07 +11:00
|
|
|
<?php
|
|
|
|
|
|
2013-12-26 12:30:36 -08:00
|
|
|
final class DrydockBlueprintViewController extends DrydockBlueprintController {
|
2013-12-03 11:09:07 +11:00
|
|
|
|
2015-07-27 07:56:52 -07:00
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
|
$viewer = $request->getViewer();
|
|
|
|
|
$id = $request->getURIData('id');
|
2013-12-03 11:09:07 +11:00
|
|
|
|
2013-12-27 13:15:19 -08:00
|
|
|
$blueprint = id(new DrydockBlueprintQuery())
|
|
|
|
|
->setViewer($viewer)
|
2015-07-27 07:56:52 -07:00
|
|
|
->withIDs(array($id))
|
2013-12-27 13:15:19 -08:00
|
|
|
->executeOne();
|
2013-12-03 11:09:07 +11:00
|
|
|
if (!$blueprint) {
|
|
|
|
|
return new Aphront404Response();
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-09 10:56:34 -08:00
|
|
|
$title = $blueprint->getBlueprintName();
|
2013-12-03 11:09:07 +11:00
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
2014-01-09 10:56:34 -08:00
|
|
|
->setHeader($title)
|
|
|
|
|
->setUser($viewer)
|
2016-03-13 08:08:45 -07:00
|
|
|
->setPolicyObject($blueprint)
|
|
|
|
|
->setHeaderIcon('fa-map-o');
|
2013-12-03 11:09:07 +11:00
|
|
|
|
2015-09-24 10:18:17 -07:00
|
|
|
if ($blueprint->getIsDisabled()) {
|
|
|
|
|
$header->setStatus('fa-ban', 'red', pht('Disabled'));
|
|
|
|
|
} else {
|
|
|
|
|
$header->setStatus('fa-check', 'bluegrey', pht('Active'));
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$curtain = $this->buildCurtain($blueprint);
|
|
|
|
|
$properties = $this->buildPropertyListView($blueprint);
|
2013-12-03 11:09:07 +11:00
|
|
|
|
|
|
|
|
$crumbs = $this->buildApplicationCrumbs();
|
2013-12-18 17:47:34 -08:00
|
|
|
$crumbs->addTextCrumb(pht('Blueprint %d', $blueprint->getID()));
|
2016-03-13 08:08:45 -07:00
|
|
|
$crumbs->setBorder(true);
|
2013-12-03 11:09:07 +11:00
|
|
|
|
2014-08-12 08:39:00 +10:00
|
|
|
$field_list = PhabricatorCustomField::getObjectFields(
|
|
|
|
|
$blueprint,
|
|
|
|
|
PhabricatorCustomField::ROLE_VIEW);
|
|
|
|
|
$field_list
|
|
|
|
|
->setViewer($viewer)
|
|
|
|
|
->readFieldsFromStorage($blueprint);
|
|
|
|
|
|
|
|
|
|
$field_list->appendFieldsToPropertyList(
|
|
|
|
|
$blueprint,
|
|
|
|
|
$viewer,
|
|
|
|
|
$properties);
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$resources = $this->buildResourceBox($blueprint);
|
|
|
|
|
$authorizations = $this->buildAuthorizationsBox($blueprint);
|
Rough cut of "Blueprint Authorizations"
Summary:
Ref T9519. This is like 80% of the way there and doesn't fully work yet, but roughly shows the shape of things to come. Here's how it works:
First, there's a new custom field type for blueprints which works like a normal typeahead but has some extra logic. It's implemented this way to make it easy to add to Blueprints in Drydock and Build Plans in Harbormaster. Here, I've added a "Use Blueprints" field to the "WorkingCopy" blueprint, so you can control which hosts the working copies are permitted to allocate on:
{F869865}
This control has a bit of custom rendering logic. Instead of rendering a normal list of PHIDs, it renders an annotated list with icons:
{F869866}
These icons show whether the blueprint on the other size of the authorization has approved this object. Once you have a green checkmark, you're good to go.
On the blueprint side, things look like this:
{F869867}
This table shows all the objects which have asked for access to this blueprint. In this case it's showing that one object is approved to use the blueprint since I already approved it, but by default new requests come in here as "Authorization Requested" and someone has to go approve them.
You approve them from within the authorization detail screen:
{F869868}
You can use the "Approve" or "Decline" buttons to allow or prevent use of the blueprint.
This doesn't actually do anything yet -- objects don't need to be authorized in order to use blueprints quite yet. That will come in the next diff, I just wanted to get the UI in reasonable shape first.
The authorization also has a second piece of state, which is whether the request from the object is active or inactive. We use this to keep track of the authorization if the blueprint is (maybe temporarily) deleted.
For example, you might have a Build Plan that uses Blueprints A and B. For a couple days, you only want to use A, so you remove B from the "Use Blueprints: ..." field. Later, you can add B back and it will connect to its old authorization again, so you don't need to go re-approve things (and if you're declined, you stay declined instead of being able to request authorization over and over again). This should make working with authorizations a little easier and less labor intensive.
Stuff not in this diff:
- Actually preventing any allocations (next diff).
- Probably should have transactions for approve/decline, at least, at some point, so there's a log of who did approvals and when.
- Maybe should have a more clear/loud error state when no blueprints are approved?
- Should probably restrict the typeahead to specific blueprint types.
Test Plan:
- Added the field.
- Typed some stuff into it.
- Saw the UI update properly.
- Approved an authorization.
- Declined an authorization.
- Saw active authorizations on a blueprint page.
- Didn't see any inactive authroizations there.
- Clicked "View All Authorizations", saw all authorizations.
Reviewers: chad, hach-que
Reviewed By: chad
Maniphest Tasks: T9519
Differential Revision: https://secure.phabricator.com/D14251
2015-10-10 07:15:25 -07:00
|
|
|
|
2014-12-03 13:16:15 -08:00
|
|
|
$timeline = $this->buildTransactionTimeline(
|
|
|
|
|
$blueprint,
|
|
|
|
|
new DrydockBlueprintTransactionQuery());
|
|
|
|
|
$timeline->setShouldTerminate(true);
|
2014-01-09 12:19:54 -08:00
|
|
|
|
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 08:06:23 -07:00
|
|
|
$log_query = id(new DrydockLogQuery())
|
|
|
|
|
->withBlueprintPHIDs(array($blueprint->getPHID()));
|
|
|
|
|
|
2018-09-14 06:56:11 -07:00
|
|
|
$log_table = $this->buildLogTable($log_query)
|
|
|
|
|
->setHideBlueprints(true);
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$logs = $this->buildLogBox(
|
2018-09-14 06:56:11 -07:00
|
|
|
$log_table,
|
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 08:06:23 -07:00
|
|
|
$this->getApplicationURI("blueprint/{$id}/logs/query/all/"));
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$view = id(new PHUITwoColumnView())
|
|
|
|
|
->setHeader($header)
|
|
|
|
|
->setCurtain($curtain)
|
|
|
|
|
->addPropertySection(pht('Properties'), $properties)
|
|
|
|
|
->setMainColumn(array(
|
|
|
|
|
$resources,
|
|
|
|
|
$authorizations,
|
|
|
|
|
$logs,
|
2014-01-09 12:19:54 -08:00
|
|
|
$timeline,
|
2016-03-13 08:08:45 -07:00
|
|
|
));
|
|
|
|
|
|
|
|
|
|
return $this->newPage()
|
|
|
|
|
->setTitle($title)
|
|
|
|
|
->setCrumbs($crumbs)
|
|
|
|
|
->appendChild(
|
|
|
|
|
array(
|
|
|
|
|
$view,
|
2013-12-03 11:09:07 +11:00
|
|
|
));
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
private function buildCurtain(DrydockBlueprint $blueprint) {
|
2015-09-24 10:18:17 -07:00
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
$id = $blueprint->getID();
|
2014-01-08 14:12:27 -08:00
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$curtain = $this->newCurtainView($blueprint);
|
2015-09-24 10:18:17 -07:00
|
|
|
$edit_uri = $this->getApplicationURI("blueprint/edit/{$id}/");
|
2013-12-03 11:09:07 +11:00
|
|
|
|
2014-01-08 14:12:27 -08:00
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
|
$viewer,
|
|
|
|
|
$blueprint,
|
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$curtain->addAction(
|
2013-12-03 11:09:07 +11:00
|
|
|
id(new PhabricatorActionView())
|
2015-09-24 10:18:17 -07:00
|
|
|
->setHref($edit_uri)
|
2014-01-08 14:12:27 -08:00
|
|
|
->setName(pht('Edit Blueprint'))
|
2014-05-12 10:08:32 -07:00
|
|
|
->setIcon('fa-pencil')
|
2014-01-08 14:12:27 -08:00
|
|
|
->setWorkflow(!$can_edit)
|
|
|
|
|
->setDisabled(!$can_edit));
|
2013-12-03 11:09:07 +11:00
|
|
|
|
2015-09-24 10:18:17 -07:00
|
|
|
if (!$blueprint->getIsDisabled()) {
|
|
|
|
|
$disable_name = pht('Disable Blueprint');
|
|
|
|
|
$disable_icon = 'fa-ban';
|
|
|
|
|
$disable_uri = $this->getApplicationURI("blueprint/{$id}/disable/");
|
|
|
|
|
} else {
|
|
|
|
|
$disable_name = pht('Enable Blueprint');
|
|
|
|
|
$disable_icon = 'fa-check';
|
|
|
|
|
$disable_uri = $this->getApplicationURI("blueprint/{$id}/enable/");
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
$curtain->addAction(
|
2015-09-24 10:18:17 -07:00
|
|
|
id(new PhabricatorActionView())
|
|
|
|
|
->setHref($disable_uri)
|
|
|
|
|
->setName($disable_name)
|
|
|
|
|
->setIcon($disable_icon)
|
|
|
|
|
->setWorkflow(true)
|
|
|
|
|
->setDisabled(!$can_edit));
|
|
|
|
|
|
2016-03-13 08:08:45 -07:00
|
|
|
return $curtain;
|
2013-12-03 11:09:07 +11:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private function buildPropertyListView(
|
2016-03-13 08:08:45 -07:00
|
|
|
DrydockBlueprint $blueprint) {
|
2016-03-03 05:52:21 -08:00
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
|
|
$view = id(new PHUIPropertyListView())
|
2016-03-13 08:08:45 -07:00
|
|
|
->setUser($viewer);
|
2013-12-03 11:09:07 +11:00
|
|
|
|
|
|
|
|
$view->addProperty(
|
2014-01-09 10:56:34 -08:00
|
|
|
pht('Type'),
|
|
|
|
|
$blueprint->getImplementation()->getBlueprintName());
|
2013-12-03 11:09:07 +11:00
|
|
|
|
|
|
|
|
return $view;
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-24 13:52:43 -07:00
|
|
|
private function buildResourceBox(DrydockBlueprint $blueprint) {
|
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
|
|
$resources = id(new DrydockResourceQuery())
|
|
|
|
|
->setViewer($viewer)
|
|
|
|
|
->withBlueprintPHIDs(array($blueprint->getPHID()))
|
|
|
|
|
->withStatuses(
|
|
|
|
|
array(
|
|
|
|
|
DrydockResourceStatus::STATUS_PENDING,
|
|
|
|
|
DrydockResourceStatus::STATUS_ACTIVE,
|
|
|
|
|
))
|
|
|
|
|
->setLimit(100)
|
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
|
|
$resource_list = id(new DrydockResourceListView())
|
|
|
|
|
->setUser($viewer)
|
|
|
|
|
->setResources($resources)
|
|
|
|
|
->render()
|
|
|
|
|
->setNoDataString(pht('This blueprint has no active resources.'));
|
|
|
|
|
|
|
|
|
|
$id = $blueprint->getID();
|
|
|
|
|
$resources_uri = "blueprint/{$id}/resources/query/all/";
|
|
|
|
|
$resources_uri = $this->getApplicationURI($resources_uri);
|
|
|
|
|
|
|
|
|
|
$resource_header = id(new PHUIHeaderView())
|
|
|
|
|
->setHeader(pht('Active Resources'))
|
|
|
|
|
->addActionLink(
|
|
|
|
|
id(new PHUIButtonView())
|
|
|
|
|
->setTag('a')
|
|
|
|
|
->setHref($resources_uri)
|
2016-01-27 20:38:01 -08:00
|
|
|
->setIcon('fa-search')
|
Rough cut of "Blueprint Authorizations"
Summary:
Ref T9519. This is like 80% of the way there and doesn't fully work yet, but roughly shows the shape of things to come. Here's how it works:
First, there's a new custom field type for blueprints which works like a normal typeahead but has some extra logic. It's implemented this way to make it easy to add to Blueprints in Drydock and Build Plans in Harbormaster. Here, I've added a "Use Blueprints" field to the "WorkingCopy" blueprint, so you can control which hosts the working copies are permitted to allocate on:
{F869865}
This control has a bit of custom rendering logic. Instead of rendering a normal list of PHIDs, it renders an annotated list with icons:
{F869866}
These icons show whether the blueprint on the other size of the authorization has approved this object. Once you have a green checkmark, you're good to go.
On the blueprint side, things look like this:
{F869867}
This table shows all the objects which have asked for access to this blueprint. In this case it's showing that one object is approved to use the blueprint since I already approved it, but by default new requests come in here as "Authorization Requested" and someone has to go approve them.
You approve them from within the authorization detail screen:
{F869868}
You can use the "Approve" or "Decline" buttons to allow or prevent use of the blueprint.
This doesn't actually do anything yet -- objects don't need to be authorized in order to use blueprints quite yet. That will come in the next diff, I just wanted to get the UI in reasonable shape first.
The authorization also has a second piece of state, which is whether the request from the object is active or inactive. We use this to keep track of the authorization if the blueprint is (maybe temporarily) deleted.
For example, you might have a Build Plan that uses Blueprints A and B. For a couple days, you only want to use A, so you remove B from the "Use Blueprints: ..." field. Later, you can add B back and it will connect to its old authorization again, so you don't need to go re-approve things (and if you're declined, you stay declined instead of being able to request authorization over and over again). This should make working with authorizations a little easier and less labor intensive.
Stuff not in this diff:
- Actually preventing any allocations (next diff).
- Probably should have transactions for approve/decline, at least, at some point, so there's a log of who did approvals and when.
- Maybe should have a more clear/loud error state when no blueprints are approved?
- Should probably restrict the typeahead to specific blueprint types.
Test Plan:
- Added the field.
- Typed some stuff into it.
- Saw the UI update properly.
- Approved an authorization.
- Declined an authorization.
- Saw active authorizations on a blueprint page.
- Didn't see any inactive authroizations there.
- Clicked "View All Authorizations", saw all authorizations.
Reviewers: chad, hach-que
Reviewed By: chad
Maniphest Tasks: T9519
Differential Revision: https://secure.phabricator.com/D14251
2015-10-10 07:15:25 -07:00
|
|
|
->setText(pht('View All')));
|
2015-09-24 13:52:43 -07:00
|
|
|
|
|
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
|
->setHeader($resource_header)
|
2016-03-13 08:08:45 -07:00
|
|
|
->setBackground(PHUIObjectBoxView::BLUE_PROPERTY)
|
2015-09-24 13:52:43 -07:00
|
|
|
->setObjectList($resource_list);
|
|
|
|
|
}
|
|
|
|
|
|
Rough cut of "Blueprint Authorizations"
Summary:
Ref T9519. This is like 80% of the way there and doesn't fully work yet, but roughly shows the shape of things to come. Here's how it works:
First, there's a new custom field type for blueprints which works like a normal typeahead but has some extra logic. It's implemented this way to make it easy to add to Blueprints in Drydock and Build Plans in Harbormaster. Here, I've added a "Use Blueprints" field to the "WorkingCopy" blueprint, so you can control which hosts the working copies are permitted to allocate on:
{F869865}
This control has a bit of custom rendering logic. Instead of rendering a normal list of PHIDs, it renders an annotated list with icons:
{F869866}
These icons show whether the blueprint on the other size of the authorization has approved this object. Once you have a green checkmark, you're good to go.
On the blueprint side, things look like this:
{F869867}
This table shows all the objects which have asked for access to this blueprint. In this case it's showing that one object is approved to use the blueprint since I already approved it, but by default new requests come in here as "Authorization Requested" and someone has to go approve them.
You approve them from within the authorization detail screen:
{F869868}
You can use the "Approve" or "Decline" buttons to allow or prevent use of the blueprint.
This doesn't actually do anything yet -- objects don't need to be authorized in order to use blueprints quite yet. That will come in the next diff, I just wanted to get the UI in reasonable shape first.
The authorization also has a second piece of state, which is whether the request from the object is active or inactive. We use this to keep track of the authorization if the blueprint is (maybe temporarily) deleted.
For example, you might have a Build Plan that uses Blueprints A and B. For a couple days, you only want to use A, so you remove B from the "Use Blueprints: ..." field. Later, you can add B back and it will connect to its old authorization again, so you don't need to go re-approve things (and if you're declined, you stay declined instead of being able to request authorization over and over again). This should make working with authorizations a little easier and less labor intensive.
Stuff not in this diff:
- Actually preventing any allocations (next diff).
- Probably should have transactions for approve/decline, at least, at some point, so there's a log of who did approvals and when.
- Maybe should have a more clear/loud error state when no blueprints are approved?
- Should probably restrict the typeahead to specific blueprint types.
Test Plan:
- Added the field.
- Typed some stuff into it.
- Saw the UI update properly.
- Approved an authorization.
- Declined an authorization.
- Saw active authorizations on a blueprint page.
- Didn't see any inactive authroizations there.
- Clicked "View All Authorizations", saw all authorizations.
Reviewers: chad, hach-que
Reviewed By: chad
Maniphest Tasks: T9519
Differential Revision: https://secure.phabricator.com/D14251
2015-10-10 07:15:25 -07:00
|
|
|
private function buildAuthorizationsBox(DrydockBlueprint $blueprint) {
|
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
|
|
|
|
|
$limit = 25;
|
|
|
|
|
|
|
|
|
|
// If there are pending authorizations against this blueprint, make sure
|
|
|
|
|
// we show them first.
|
|
|
|
|
|
|
|
|
|
$pending_authorizations = id(new DrydockAuthorizationQuery())
|
|
|
|
|
->setViewer($viewer)
|
|
|
|
|
->withBlueprintPHIDs(array($blueprint->getPHID()))
|
|
|
|
|
->withObjectStates(
|
|
|
|
|
array(
|
|
|
|
|
DrydockAuthorization::OBJECTAUTH_ACTIVE,
|
|
|
|
|
))
|
|
|
|
|
->withBlueprintStates(
|
|
|
|
|
array(
|
|
|
|
|
DrydockAuthorization::BLUEPRINTAUTH_REQUESTED,
|
|
|
|
|
))
|
|
|
|
|
->setLimit($limit)
|
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
|
|
$all_authorizations = id(new DrydockAuthorizationQuery())
|
|
|
|
|
->setViewer($viewer)
|
|
|
|
|
->withBlueprintPHIDs(array($blueprint->getPHID()))
|
|
|
|
|
->withObjectStates(
|
|
|
|
|
array(
|
|
|
|
|
DrydockAuthorization::OBJECTAUTH_ACTIVE,
|
|
|
|
|
))
|
|
|
|
|
->withBlueprintStates(
|
|
|
|
|
array(
|
|
|
|
|
DrydockAuthorization::BLUEPRINTAUTH_REQUESTED,
|
|
|
|
|
DrydockAuthorization::BLUEPRINTAUTH_AUTHORIZED,
|
|
|
|
|
))
|
|
|
|
|
->setLimit($limit)
|
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
|
|
$authorizations =
|
|
|
|
|
mpull($pending_authorizations, null, 'getPHID') +
|
|
|
|
|
mpull($all_authorizations, null, 'getPHID');
|
|
|
|
|
|
|
|
|
|
$authorization_list = id(new DrydockAuthorizationListView())
|
|
|
|
|
->setUser($viewer)
|
|
|
|
|
->setAuthorizations($authorizations)
|
|
|
|
|
->setNoDataString(
|
|
|
|
|
pht('No objects have active authorizations to use this blueprint.'));
|
|
|
|
|
|
|
|
|
|
$id = $blueprint->getID();
|
|
|
|
|
$authorizations_uri = "blueprint/{$id}/authorizations/query/all/";
|
|
|
|
|
$authorizations_uri = $this->getApplicationURI($authorizations_uri);
|
|
|
|
|
|
|
|
|
|
$authorizations_header = id(new PHUIHeaderView())
|
|
|
|
|
->setHeader(pht('Active Authorizations'))
|
|
|
|
|
->addActionLink(
|
|
|
|
|
id(new PHUIButtonView())
|
|
|
|
|
->setTag('a')
|
|
|
|
|
->setHref($authorizations_uri)
|
2016-01-27 20:38:01 -08:00
|
|
|
->setIcon('fa-search')
|
Rough cut of "Blueprint Authorizations"
Summary:
Ref T9519. This is like 80% of the way there and doesn't fully work yet, but roughly shows the shape of things to come. Here's how it works:
First, there's a new custom field type for blueprints which works like a normal typeahead but has some extra logic. It's implemented this way to make it easy to add to Blueprints in Drydock and Build Plans in Harbormaster. Here, I've added a "Use Blueprints" field to the "WorkingCopy" blueprint, so you can control which hosts the working copies are permitted to allocate on:
{F869865}
This control has a bit of custom rendering logic. Instead of rendering a normal list of PHIDs, it renders an annotated list with icons:
{F869866}
These icons show whether the blueprint on the other size of the authorization has approved this object. Once you have a green checkmark, you're good to go.
On the blueprint side, things look like this:
{F869867}
This table shows all the objects which have asked for access to this blueprint. In this case it's showing that one object is approved to use the blueprint since I already approved it, but by default new requests come in here as "Authorization Requested" and someone has to go approve them.
You approve them from within the authorization detail screen:
{F869868}
You can use the "Approve" or "Decline" buttons to allow or prevent use of the blueprint.
This doesn't actually do anything yet -- objects don't need to be authorized in order to use blueprints quite yet. That will come in the next diff, I just wanted to get the UI in reasonable shape first.
The authorization also has a second piece of state, which is whether the request from the object is active or inactive. We use this to keep track of the authorization if the blueprint is (maybe temporarily) deleted.
For example, you might have a Build Plan that uses Blueprints A and B. For a couple days, you only want to use A, so you remove B from the "Use Blueprints: ..." field. Later, you can add B back and it will connect to its old authorization again, so you don't need to go re-approve things (and if you're declined, you stay declined instead of being able to request authorization over and over again). This should make working with authorizations a little easier and less labor intensive.
Stuff not in this diff:
- Actually preventing any allocations (next diff).
- Probably should have transactions for approve/decline, at least, at some point, so there's a log of who did approvals and when.
- Maybe should have a more clear/loud error state when no blueprints are approved?
- Should probably restrict the typeahead to specific blueprint types.
Test Plan:
- Added the field.
- Typed some stuff into it.
- Saw the UI update properly.
- Approved an authorization.
- Declined an authorization.
- Saw active authorizations on a blueprint page.
- Didn't see any inactive authroizations there.
- Clicked "View All Authorizations", saw all authorizations.
Reviewers: chad, hach-que
Reviewed By: chad
Maniphest Tasks: T9519
Differential Revision: https://secure.phabricator.com/D14251
2015-10-10 07:15:25 -07:00
|
|
|
->setText(pht('View All')));
|
|
|
|
|
|
|
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
|
->setHeader($authorizations_header)
|
2016-03-13 08:08:45 -07:00
|
|
|
->setBackground(PHUIObjectBoxView::BLUE_PROPERTY)
|
Rough cut of "Blueprint Authorizations"
Summary:
Ref T9519. This is like 80% of the way there and doesn't fully work yet, but roughly shows the shape of things to come. Here's how it works:
First, there's a new custom field type for blueprints which works like a normal typeahead but has some extra logic. It's implemented this way to make it easy to add to Blueprints in Drydock and Build Plans in Harbormaster. Here, I've added a "Use Blueprints" field to the "WorkingCopy" blueprint, so you can control which hosts the working copies are permitted to allocate on:
{F869865}
This control has a bit of custom rendering logic. Instead of rendering a normal list of PHIDs, it renders an annotated list with icons:
{F869866}
These icons show whether the blueprint on the other size of the authorization has approved this object. Once you have a green checkmark, you're good to go.
On the blueprint side, things look like this:
{F869867}
This table shows all the objects which have asked for access to this blueprint. In this case it's showing that one object is approved to use the blueprint since I already approved it, but by default new requests come in here as "Authorization Requested" and someone has to go approve them.
You approve them from within the authorization detail screen:
{F869868}
You can use the "Approve" or "Decline" buttons to allow or prevent use of the blueprint.
This doesn't actually do anything yet -- objects don't need to be authorized in order to use blueprints quite yet. That will come in the next diff, I just wanted to get the UI in reasonable shape first.
The authorization also has a second piece of state, which is whether the request from the object is active or inactive. We use this to keep track of the authorization if the blueprint is (maybe temporarily) deleted.
For example, you might have a Build Plan that uses Blueprints A and B. For a couple days, you only want to use A, so you remove B from the "Use Blueprints: ..." field. Later, you can add B back and it will connect to its old authorization again, so you don't need to go re-approve things (and if you're declined, you stay declined instead of being able to request authorization over and over again). This should make working with authorizations a little easier and less labor intensive.
Stuff not in this diff:
- Actually preventing any allocations (next diff).
- Probably should have transactions for approve/decline, at least, at some point, so there's a log of who did approvals and when.
- Maybe should have a more clear/loud error state when no blueprints are approved?
- Should probably restrict the typeahead to specific blueprint types.
Test Plan:
- Added the field.
- Typed some stuff into it.
- Saw the UI update properly.
- Approved an authorization.
- Declined an authorization.
- Saw active authorizations on a blueprint page.
- Didn't see any inactive authroizations there.
- Clicked "View All Authorizations", saw all authorizations.
Reviewers: chad, hach-que
Reviewed By: chad
Maniphest Tasks: T9519
Differential Revision: https://secure.phabricator.com/D14251
2015-10-10 07:15:25 -07:00
|
|
|
->setObjectList($authorization_list);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-24 13:52:43 -07:00
|
|
|
|
2013-12-03 11:09:07 +11:00
|
|
|
}
|