Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class AlmanacProperty
|
2016-02-22 15:35:30 +01:00
|
|
|
extends AlmanacDAO
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
implements PhabricatorPolicyInterface {
|
|
|
|
|
2016-02-22 15:35:30 +01:00
|
|
|
protected $objectPHID;
|
|
|
|
protected $fieldIndex;
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
protected $fieldName;
|
2016-02-22 15:35:30 +01:00
|
|
|
protected $fieldValue;
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
|
|
|
|
private $object = self::ATTACHABLE;
|
|
|
|
|
2015-01-13 20:47:05 +01:00
|
|
|
protected function getConfiguration() {
|
2016-02-22 15:35:30 +01:00
|
|
|
return array(
|
|
|
|
self::CONFIG_TIMESTAMPS => false,
|
|
|
|
self::CONFIG_SERIALIZATION => array(
|
|
|
|
'fieldValue' => self::SERIALIZATION_JSON,
|
|
|
|
),
|
|
|
|
self::CONFIG_COLUMN_SCHEMA => array(
|
|
|
|
'fieldIndex' => 'bytes12',
|
|
|
|
'fieldName' => 'text128',
|
|
|
|
),
|
|
|
|
self::CONFIG_KEY_SCHEMA => array(
|
|
|
|
'objectPHID' => array(
|
|
|
|
'columns' => array('objectPHID', 'fieldIndex'),
|
|
|
|
'unique' => true,
|
|
|
|
),
|
|
|
|
),
|
|
|
|
) + parent::getConfiguration();
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
public function getObject() {
|
|
|
|
return $this->assertAttached($this->object);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function attachObject(PhabricatorLiskDAO $object) {
|
|
|
|
$this->object = $object;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
Store Almanac "service types" instead of "service classes"
Summary:
Ref T10449. Currently, we store classes (like "AlmanacClusterRepositoryServiceType") in the database.
Instead, store types (like "cluster.repository").
This is a small change, but types are a little more flexible (they let us freely reanme classes), a little cleaner (fewer magic strings in the codebase), and a little better for API usage (they're more human readable).
Make this minor usability change now, before we unprototype.
Also make services searchable by type.
Also remove old Almanac API endpoints.
Test Plan:
- Ran migration, verified all data migrated properly.
- Created, edited, rebound, and changed properties of services.
- Searched for services by service type.
- Reviewed available Conduit methods.
Reviewers: chad
Reviewed By: chad
Subscribers: yelirekim
Maniphest Tasks: T10449
Differential Revision: https://secure.phabricator.com/D15346
2016-02-25 14:05:36 +01:00
|
|
|
public static function newPropertyUpdateTransactions(
|
|
|
|
AlmanacPropertyInterface $object,
|
|
|
|
array $properties,
|
|
|
|
$only_builtins = false) {
|
|
|
|
|
|
|
|
$template = $object->getApplicationTransactionTemplate();
|
|
|
|
$builtins = $object->getAlmanacPropertyFieldSpecifications();
|
|
|
|
|
|
|
|
$xactions = array();
|
|
|
|
foreach ($properties as $name => $property) {
|
|
|
|
if ($only_builtins && empty($builtins[$name])) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
$xactions[] = id(clone $template)
|
|
|
|
->setTransactionType(AlmanacTransaction::TYPE_PROPERTY_UPDATE)
|
|
|
|
->setMetadataValue('almanac.property', $name)
|
|
|
|
->setNewValue($property);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $xactions;
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function newPropertyRemoveTransactions(
|
|
|
|
AlmanacPropertyInterface $object,
|
|
|
|
array $properties) {
|
|
|
|
|
|
|
|
$template = $object->getApplicationTransactionTemplate();
|
|
|
|
|
|
|
|
$xactions = array();
|
|
|
|
foreach ($properties as $property) {
|
|
|
|
$xactions[] = id(clone $template)
|
|
|
|
->setTransactionType(AlmanacTransaction::TYPE_PROPERTY_REMOVE)
|
|
|
|
->setMetadataValue('almanac.property', $property)
|
|
|
|
->setNewValue(null);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $xactions;
|
|
|
|
}
|
|
|
|
|
2016-02-22 15:35:30 +01:00
|
|
|
public function save() {
|
|
|
|
$hash = PhabricatorHash::digestForIndex($this->getFieldName());
|
|
|
|
$this->setFieldIndex($hash);
|
|
|
|
|
|
|
|
return parent::save();
|
2015-03-23 17:10:42 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Give Almanac generic, custom-field-based properties
Summary:
Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic:
- Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc).
- Make properties more generic so Services, Bindings and Devices can all have them.
The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is.
I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them.
This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense.
Test Plan: {F229172}
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5833
Differential Revision: https://secure.phabricator.com/D10777
2014-11-06 00:27:16 +01:00
|
|
|
/* -( PhabricatorPolicyInterface )----------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getCapabilities() {
|
|
|
|
return array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getPolicy($capability) {
|
|
|
|
return $this->getObject()->getPolicy($capability);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasAutomaticCapability($capability, PhabricatorUser $viewer) {
|
|
|
|
return $this->getObject()->hasAutomaticCapability($capability, $viewer);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function describeAutomaticCapability($capability) {
|
|
|
|
return pht('Properties inherit the policies of their object.');
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|